三層體系結構總結（五）

在這次項目開發中，我們對以前用的三層結構有進行了進一步的改變，除了使用Castle的Windsor容器來管理BLL層和DAL層，在資料的封裝和對資料的讀取上比以前更加面向對象。

1、              對于BLL層和DAL層的類型，分别繼承各自的IBLL和IDAL，使用Windsor容器以注入的方式對其進行執行個體化，這一點和上次一樣，不再贅述。

2、              對于Model層有了一些改進。每一個Model類型會對應一個ModelCollection集合類型，例如：對于訂單Order實體會有相對應的OrderCollection實體集合類型。這個集合類型繼承自List<T>類型，如下：

public class OrderCollection:List<Order>

                           //List<T>是一個泛型類型

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();

}

                        BLL:

                                    Update()

                                    {

                                                If(UpdateFlag)

                                                {

                                                            DAL.Update();

                                                Else

                                                            DAL.Delete();

                        DAL:

                                    Update();

                                    Delete();

還有，比如使用者在界面上的多個類似改變狀态的按鈕，對于UI層來說應該是多個方法，調用的BLL也應該是多個方法，但是DAL層才應該調用一個方法，而不應該将要改變的狀态在UI層就組裝好。

                        UI：

                                    ChangeStateToTrue()

{

BLL.ChangeStateToTrue();

                                    ChangeStateToFalse()

BLL.ChangeStateToFalse();

                        BLL：

ChangeState (True)

ChangeState (False)

                        DAL：

                                    ChangeState(State)

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

2、 在系統中往往會存在很多的狀态，将這些狀态提取出來，作為一個單獨的項目，可以使用枚舉來封裝，可以提高代碼的可讀性，也給今後做這件事的人以友善,而且可以到達統一的效果.

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

項目中的一些遺憾：

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