第二種我所見過的三層設計模式是：
還是分為ui層、業務層（bll）、資料訪問層（dal），但其中的資料的儲存和傳遞使用的是model類，model類中只有私有欄位和公有的屬性，並不存在對資料的操作，定義邏輯業務實體，但是實體的定義並不是以單錶定義的，而是以乙個業務邏輯來定義。
我所遇到的問題是，隨著開發的深入，對使用者需求的深入，需求在變化，大多是需求膨脹，就某乙個邏輯業務實體來說就會不斷地膨脹。這樣為了實現乙個操作有可能要例項化乙個很大的實體類，而實際上這個實體類中有用的資訊並不多。這樣就會造成整體效能的下降。
三層體系結構總結（四）
前一段時間幫乙個專案組做他們的專案，有幸了解了一下他搭建的架構。相比起以前所見過的架構，我覺得這個應該算是不錯的。大體結構如下圖 1 層與層之間依賴於介面 ui依賴於ibll，ibll依賴於idal，這樣做在設計模式中叫做依賴倒置。也就是說依賴於抽象，而不是具體實現。如果今後的業務邏輯有變動可以不變...
三層體系結構總結（五）
在這次專案開發中，我們對以前用的三層結構有進行了進一步的改變，除了使用castle的windsor容器來管理bll層和dal層，在資料的封裝和對資料的讀取上比以前更加物件導向。1 對於bll層和dal層的型別，分別繼承各自的ibll和idal，使用windsor容器以注入的方式對其進行例項化，這一點...
三層體系結構總結（五）
在這次專案開發中，我們對以前用的三層結構有進行了進一步的改變，除了使用castle的windsor容器來管理bll層和dal層，在資料的封裝和對資料的讀取上比以前更加物件導向。1 對於bll層和dal層的型別，分別繼承各自的ibll和idal，使用windsor容器以注入的方式對其進行例項化，這一點...