如何構建3層解決方案？

我在我的解決方案中使用FluentNHibernate。從fluentnhibernate文檔中推薦的文件夾結構如下所示：如何構建3層解決方案？

實體文件夾，我們在其中擁有業務模型的POCO類。 Mappings文件夾，在其下我們有映射到我們的數據模型。

我假設這兩個文件夾將進入名爲「BusinessModel」的業務層項目？請看下圖：

BuessinessModel 
    |_ Entities 
      |- Student.cs 
      |- Course.cs 
      |- Faculty.cs 
    |_ Mappings 
      |- Mappings.cs

也許創建一個名爲「數據訪問」另一個項目，引用商業模式項目的數據訪問層做CRUD？

最佳做法是什麼？那裏有建築師嗎？謝謝。

AK：我在n-layered architecture - BLL, DAL and interfaces. What is best practice?上看過你的文章。

讓我給你

以「人」爲例：考慮不同的數據有一個人（獲得的所有數據單個人，淺淺的數據的集合相關操作對於許多人來說，CRUD 操作，搜索等） - 然後沿着邏輯分組設計界面。

我想了解這一點。所以，你說的是

在BLL項目中，我們有這個Person類。
另外在BLL項目中，我們有一個接口，它聲明瞭Person對象需要的所有數據的操作方法。
然後在DAL項目中，我們具體實現了我們在BLL中定義的接口。

這聽起來對你正確嗎？謝謝。

來源

2011-09-13 Stack0verflow

雖然盲目地將相同的體系結構應用於每個解決方案/項目是危險的，我的標準/默認的做法是這樣的：

高層

我們的目標爲3層級，我們假設是：UI，BL（業務邏輯），DA（數據訪問）。
這可能（可能）由以下4個邏輯塊（思想命名空間）組成：Common，UI，BL，DA。請記住，這4個塊中的每一塊都可能有多個代碼級項目。
通常情況下，我們將堅持其他3個人需要分享的東西 - 例如POCO。

你的具體細節內常見

製作商業模式（可能作爲一個獨立的項目）。
映射我猜是依賴於物理數據源，所以應該進入具體的DA實現。

其他注意事項

最佳/常見的做法是鬆散耦合我們的主要塊（尤其是BL和DA）;通常使用依賴注入。
這將通過定義Inferfaces來實現，並且這些接口將會/可以使用來自Common的POCO或BusinessModel實體。

來源

2011-09-14 01:22:28

謝謝，這很有幫助。我是否在所有層或僅在DA層定義接口？指向任何好文章？我知道我可以谷歌，但我相信我會挖出一大堆，不知道哪一個能幫助我最好。 – Stack0verflow

您需要將具體數據訪問與業務層分開，最好創建一個包含實體（域模型）和存儲庫接口的業務層。

然後創建數據訪問的具體實現，其中包含使用fluentnhibernate進行數據訪問的映射和具體存儲庫。

來源

2011-09-14 09:54:22

謝謝，MA。這很好。我有點想法。假設我有一個小型解決方案，每層只有一個項目，那麼在業務模型中，我擁有POCO和存儲庫接口。那麼，在DAL中，具體的存儲庫類實際上是否實現了業務層中定義的存儲庫接口？你能確認嗎？我認爲這將幫助我在正確的方向上組織我的解決方案結構。再次感謝你。 – Stack0verflow

是的，你正確的做法是，在業務模型中使用POCO和存儲庫接口，並且在實現接口的dal項目中有具體的存儲庫具體類。你也可以找到很多實現這種架構的DDD示例..查看我一直在開發的這個解決方案，它稍微複雜一點，但它會給你一個想法http://sellandbuy.codeplex.com/ –

如何構建3層解決方案？

回答

相關問題