我們正在修改我們的架構和應用程序設計。我們剛剛完成了數據訪問層的設計，這是通用的，它使用XML和反射來保存數據。業務層設計
現在我們處於業務層設計階段的任何方式。我們已經閱讀了一些與企業架構和設計相關的書籍，因此我們發現可以在業務層上應用的模式很少。表格模式和領域模型就是這種模式的例子。我們也發現了領域驅動設計。
此前我們決定針對表對象構建實體。但是我們發現，在DDD方面，實體和價值對象存在差異。對於那些經歷過這種設計的人。請引導我相關的模式，實踐和樣本。
預先感謝您！如果您沒有得到任何意見，請隨時與我們商量。
CSLA.NET很適合作爲業務層的基礎。
@Adil，
我不是很experient用戶，無論如何，這是模型的那種我使用（也與NHibernate）。
GUI - 所有的網頁表單等 BLL - 這是負責創建新對象 DAL的情況下的目錄 - 在負責交互類與NHibernate實現的地方。 NHibernate映射文件在這裏。
模型 - 由BLL和DAL用於數據傳輸對象之間的類庫。
使用不同的圖案。例如，BLL和DAL有一個允許訪問接口的Factory類。目錄是Singleton類。所有目錄的使用訪問代表我的業務邏輯主Singleton類頂級對象（例如，「企業」 =>「Enterprise.PeopleCatalog」。
不管怎麼說，希望這有助於...
@AngryHacker，感謝您的提示，你可以給一個CSLA.NET的例子嗎？
@Adil，這不是你原來的問題的答案，但我建議你修改你的決定，推出自己的數據訪問層。注意，你想去NHibernate：現在就做吧
國際海事組織，寫一個ORM是浪費時間，除非你有一些非常具體的限制。這裏有很多選擇，已經有數百小時的努力。利用它！ LINQ2SQL，Entity框架，NHibernate，Subsonic，LLBLGen都很好，還有更多。
請注意，如果你自己推出，你將無法使用LINQ的優點，而無需付出很多努力。
就分層而言，儘量不要發瘋：保持圖層的數量，集中精力建立一個有價值的界面，以防止抽象泄漏。
我見過很多非常「有圖案」的，精美的分層項目，最終使用的邏輯隨處可見，並且持久性抽象泄漏到各處。把事情簡單化！
另外，我們可能需要將來使用NHibernate！ – 2010-05-25 05:59:04