三層體系結構總結（五）

在這次專案開發中，我們對以前用的三層結構有進行了進一步的改變，除了使用castle的windsor容器來管理bll層和dal層，在資料的封裝和對資料的讀取上比以前更加物件導向。

1、對於bll層和dal層的型別，分別繼承各自的ibll和idal，使用windsor容器以注入的方式對其進行例項化，這一點和上次一樣，不再贅述。

2、對於model層有了一些改進。每乙個model型別會對應乙個modelcollection集合型別，例如：對於訂單order實體會有相對應的ordercollection實體集合型別。這個集合型別繼承自list型別，如下：

public class ordercollection:list

//list是乙個泛型型別

3、對於modelcollection型別中只有乙個方法，就是將讀取出的資料集合轉化為指定model的物件集合

4、在model定義中也和以往簡單的資料表字段封裝不同，應該說加入了少量的業務邏輯。比如說：

order的實體型別中定義了orderdetailcollection，也就是說明order與orderdetail是一對多的關係，orderdetail實體中加入乙個order實體物件

5、對於日誌的實現加入了aop的思想，使用castle中的facility.aspectsharp，對於要加入日誌的方法加了乙個attribute標籤，在容器中截獲方法呼叫的訊息。這樣可以減少在系統成型後加入日誌帶來的修改量

專案中的心得：

1、對於三層來說ui層、bll層和dal層要分別寫入相應的**，在這次專案中感覺我們往往會把業務層中的**寫到其他的層中，比如說：有乙個需求是這樣的，使用者要減少訂單中某件物品的採購數量，當使用者減少部分數量時，應該對相應記錄使用update操作，當使用者減少全部數量時，應該刪除相應的記錄。我原來對這種判斷往往會放在ui層來判斷，這次專案中我體會到，對於ui層應該只是呼叫一種方法，bll層做判斷

ui：click()

bll:

update()

else

}dal:

update();

delete();

還有，比如使用者在介面上的多個類似改變狀態的按鈕，對於ui層來說應該是多個方法，呼叫的bll也應該是多個方法，但是dal層才應該呼叫乙個方法，而不應該將要改變的狀態在ui層就組裝好。

ui：changestatetotrue()

changestatetofalse()

bll：

changestatetotrue()

changestatetofalse()

dal：

changestate(state)

這些問題也許並不感覺什麼嚴重，但是層次間的功能相對更清晰，也有助於我們進行橫向開發

2、在系統中往往會存在很多的狀態，將這些狀態提取出來，作為乙個單獨的專案，可以使用列舉來封裝，可以提高**的可讀性，也給今後做這件事的人以方便,而且可以到達統一的效果.

3、系統中的綜合查詢部分，對於結果的傳遞沒有使用實體類進行傳遞，後來感覺綜合查詢本身就很靈活多變，用實體類去傳遞結果，顯得有些困難。而且結果集本身就是依靠多個實體及實體間關係得出，又如何用乙個實體去傳遞。即使對於每乙個查詢建立乙個實體，對於今後的改動又如何很好的應對呢

專案中的一些遺憾：

開始想使用castle中的ar建立orm，但是出了一些問題，應該算是有些遺憾吧。所以後來自己去寫實體中的關係，有些地方還是有些牽強，今後要加強學習

三層體系結構總結（五）

三層體系結構總結（五）

三層體系結構總結（四）

三層體系結構總結（二）

三層體系結構總結（五）

三層體系結構總結（五）

三層體系結構總結（四）

三層體系結構總結（二）

相關推薦