Web應用架構探索筆記查詢

在web應用開發中，最常見也容易變化的一種需求是根據不同的查詢條件獲取資料列表。如何傳遞查詢條件將影響程式應對需求變化的能力，一定要在架構中重點考慮。

開始時我們使用一堆引數傳遞查詢條件，比如：

list
<
sitemsg
>
getmsglist(
intpageindex, 
intpagesize, 
intrecipientid);

結果，每個不同的查詢都要寫乙個介面，產生了一堆介面；查詢條件改變，介面也隨之要改。寫程式最痛苦的事莫過於介面的頻繁變化。

後來使用查詢對像，比如：

list
<
sitemsg
>
getmsglist(sitemsgquery msgquery);

這樣，查詢條件改變時，只需修改sitemsgquery的定義，介面保持不變。採用這個方法後，寫**比之前少了很多痛苦。

但使用這個方法有個地方不爽，完成一次查詢需要進行兩次例項化，一次是查詢物件sitemsgquery的例項化，一次是領域物件sitemsgmanager（負責業務邏輯）的例項化。在程式架構中，查詢物件的例項化是在表現層完成的，如果是ajax呼叫，json會自動反串行為查詢物件；領域物件的例項化在服務層完成。

為了讓**寫的更爽一些，我們又進行了嘗試，取消查詢物件sitemsgquery，將它的屬性放到領域物件中。這樣減少了一次例項化，只需一次，如果是ajax呼叫，可以實現伺服器端「零例項化」。

下面看一下**示例：

領域模型的定義：

[datacontract]
public
class
sitemsgmanager
#region
properies
[datamember]
public
intpageindex 
[datamember]
public
intpagesize 
[datamember]
public
intrecipientid 
public
list
<
sitemsg
>
list 
#endregion
public
void
getlist()
}

服務實現類（也是wcf的服務實現）：

public
class
msgservice : imsgservice
}

ui層呼叫**（wcf呼叫，asp.net mvc控制器）：

public
class
msgcontroller : controller
public
actionresult inbox()
; 
return
view(
"inbox
", getinboxmsglist(msgmanager));
}private
list
<
sitemsg
>
getinboxmsglist(sitemsgmanager msgmanager)
catch
return
sitemsglist;}}

看看上面供ajax呼叫的list方法，不需要進行sitemsgmanager的例項化，系統根據ajax客戶端傳遞過來的json引數自動反序列化生成sitemsgmanager物件。

再來看看ajax客戶端**：

function
getmsglist(pageindex, pagesize) 
msgmanager.pageindex 
=pageindex;
msgmanager.pagesize 
=pagesize;
$.ajaxsettings.datatype ='
plain/text
'; 
$.ajaxsettings.url ='
/msg/list';
$.ajaxsettings.data ='
';$.ajaxsettings.success 
=function
(data) ;
$.ajax();
}

js傳遞的也是乙個對像。

整個ajax呼叫的流程是這樣的：js物件(msgmanager)->json->msgcontroller(mvc控制器)->**領域物件sitemsgmanager(wcf客戶端**類的例項)->wcf服務介面->wcf服務實現(自動通過反序列化生成領域物件sitemsgmanager，並呼叫getlist()方法)->領域物件完成業務邏輯操作返回資料。

採用這種方法，感覺寫**比以前更享受了。我們在實際開發中也開始使用這種架構，並根據實際使用情況進一步改進。

注：這篇隨筆只是我們在探索web應用架構過程中的筆記，並不代表這是更好更合理的方法。寫出來一是為了分享，二是幫助自己更好的思考，三是記錄架構演變的過程。

Web應用架構探索筆記查詢

web應用基礎架構

反應製作的web應用轉場動畫探索

基於AWS雲服務的Web應用架構

Web應用架構探索筆記 查詢

web應用基礎架構

反應製作的web應用轉場動畫探索

基於AWS雲服務的Web應用架構

相關推薦

Web應用架構探索筆記查詢