在《企業級應用架構》系列文章發表之余，也得到了許多同行的反饋，有人說這套框架太重了或者技術學習太復雜了或者初學者不太好理解或者完全顛覆了傳統APS.NET開發模式讓人望而生畏。這些理由在筆者看來確實是問題，但筆者也不得不說，那樣的框架組合架構在某些企業級應用中是必須的，因為它有着傳統asp.net開發模式無可比擬的多項優勢，還望初學者能夠堅持下來。
另外鑒於此，經過我親身實踐項目，現推出一個更加輕量級，更容易學習，更適合許多公司日常開發的部門級管理系統業務的新框架體系結構。這就是本文今日的主題。
主要框架組件：ASP.NET、Spring.NET、NHibernate、Log4Net、NUnit、Membership、EasyUI
架構圖：
下圖來源於筆者實際項目架構圖。
總體來說，項目架構依然實現經典的三層架構，前端MVC模式采用多數人熟悉的基於事件通信模式的ASP.NET框架，這是一個優秀的MVC實現模式，在經典Java EE中，sun公司也將這種基於事件通信模式的JSF作為前端MVC的標准。而Spring.Net和NHibernate的作用和地位，我也不多說了，相信看過前面的系列文章的同行早已知曉。
在我們許多管理系統中因為很多都是些增刪改的數據邏輯操作，所以我們的Service層就會變得很瘦，因為許多構建數據查詢條件的代碼都被分離到Dao層中去了。故與之前的架構相比我們少了隔離層，但在這里我們將原來在隔離層中的數據驗證、類型轉換、異常捕獲等工作全部交由Service來完成，這樣變可以減少一個中間層，同時也不會讓Service層感覺到太瘦小。
另外一個重要應用是，任然使用DTO（數據傳輸對象模式）作為業務層和表現層數據交換的載體，與數據實體（或領域層）徹底隔離，這樣做的好處是相當明顯的，不會讓底層業務對象參與到表現層中來，從而達到解耦的目的。雖然這樣也在一定程度上增加了代碼量，但我覺得還是很值得的，這些代碼不會很復雜，只是多一點而已。有個方法是Domain中的數據庫實體和DTO中的對象都可以使用模版來生成，且完全可以保持DTO實體的屬性和Entity的屬性是完全相同的，我的意思是一次性生成DTO時，開發過程中DTO屬性肯定是要擴展的，因為DTO包裝的數據應該直接反映頁面的需求，如：一個員工所屬的部門名稱，這在Entity類中員工實體需要訪問部門實體的名稱屬性才能得到，但DTO對象就不用了，可以直接在員工類中自定義其部門名稱，在Service層中直接將這個名稱賦值給員工DTO對象的該屬性即可，這樣前端表格取數據時可以直接綁定該屬性，這可以最大程度的減少表現層代碼，從而降低表現層耦合度。達到業務代碼級重用。自定義屬性可以使用C#語法中的Partial關鍵字聲明DTO對象實現，這樣同樣可以降低DTO模版生成類和自定義類之間的耦合，如果你覺得由Entity轉Dto對象代碼量大，你也可以選擇使用AutoMapp這樣的中間件來幫助你。說道這里可能有點復雜，下面給個簡單的圖示說明之。
Common為公共組件或代碼模塊，其也有一個抽象層，比如說Log4Net組件，他是屬於第三方組件，且幾乎每個層都會使用到，所以我們不好將其歸為某個一層而使用，而是將其歸為公共層。其使用一個接口訪問，那是因為我們應用程序不需要強制依賴這個Log4net組件，而將來可以任意更換為別的日志組件如果有更好的。這樣就可以做到更高級別的應用程序重用效果。
NUnit涉及到兩層，但它不作為應用程序的一部分發布。一幫來說，單元測試需要測試Dao層和Service層。如果你的系統簡單，只測試Service層也可以。
本系統Dao異常捕獲使用了Spring.net的AOP技術，這樣可以讓Dao層代碼看起來更加簡介。
本文章只提供基本的架構示例代碼，不會提供完整的項目事例，這是為了保護原公司著作權和版權。另外提供生成Dto和Domain、Dao等層和相關配置文件的生成模版（Codesmith）。具體使用我不詳述。注意這個模版生成的實體對象對於自關聯的實體，還需要手動修改其對於自身引用對象賦null值，否則會引發堆棧溢出異常！另外還有一些一對多關系，也需要手動添加解決。望大家見諒！這些問題需要你比較了解NHibernate。如果對本架構有不理解之處，請參見筆者之前《企業級應用架構XXX》系列文章。
運行本事例，請自行下載NorthWind數據庫。
示例代碼：