n層體系結構 - BLL，DAL和接口。什麼是最佳做法？

我有一個關於n層體系結構的問題。在提出這個問題之前，我想了很久並且很努力，因爲這裏已經有很多類似的問題了......但是，在一天半的時間裏看完這些問題並閱讀其他答案後，我仍然不確定。各種看似相似的術語和不同的方法讓我感到困惑。n層體系結構 - BLL，DAL和接口。什麼是最佳做法？

如果我在不同的類庫中有一個BLL和一個DAL，BLL和DAL之間進行通信的一種方法是利用一個接口，類似於另一個獨立DLL中定義的DTO，BLL和DAL。 BLL中的我的領域模型實體將實現此接口，DAL中的任何ORM生成的對象也將實現此接口。爲了保存我的業務實體，我可以將它們傳遞給DAL，因爲它們實現了共享接口，所以它們可以很好地接受它們。我也可以將對象傳遞迴實現此接口的BLL。這似乎是合理的，因爲BLL和DAL都只需要知道基本接口，而不是其他的具體實現。

我的問題是什麼是在另一邊創建對象的最佳方法是什麼？例如，如果我在實現IPerson的BLL中有一個Person對象，並且還有一個PersonDataObject或者實現IPerson的DLL中的任何對象，我將Person傳遞給DAL中的一個方法，該方法需要IPerson的參數，然後在DAL中， d必須重構一個PersonDataObject來保存。這甚至是最好的方法嗎？

對不起，我可能沒有解釋得這麼好，因爲我很困惑。對於傻瓜答案的最佳做法將不勝感激。

來源

2010-06-25 nukefusion

一般來說，在BLL的對象會消耗接口 - 沒有實現他們：

例如，如果我不得不在BLL Person對象是實現IPerson，和PersonDataObject或任何在同時實現IPerson的DLL

以「Person」爲例：思考與某人關聯的不同數據操作（獲取單個人的所有數據，獲取許多人的淺數據集合， CRUD操作，搜索等） - 然後沿着邏輯分組設計界面（請參閱Interface Segeragtion Principle）。

這些接口可能代表以BL爲中心的操作 - 或基於「服務」的操作。

無論如何，回答您的具體問題......

我定義我的DTO相當於公司的一個共同的組件，並在單獨的一個數據接口以及 - 所以我有4個組件：BL，數據訪問接口定義，接口實現和通用;所有程序集都引用常見的程序集我正在C＃.Net中工作，我將DTO定義爲結構體（但您可以使用類）;並且它們的所有屬性都是隻讀的 - 在構造函數中向它們提供數據 - 這樣DTO就是有效的「啞」信息包絡。

來源

2010-06-27 00:03:25

而我忘了包括的內容：讓BL調用一個「Factory」方法，它負責實例化具體的實現;我傾向於在配置中將它們定義爲易於更改。 – 2010-06-27 05:40:46

Google針對域驅動設計和存儲庫模式。它聽起來像你正朝着你的架構朝着這個方向前進，並且依賴於場景的保證，我會在更復雜的代碼中使用這種方法。

來源

2010-06-25 23:01:34 Burt

雖然遵循n層架構，但在BL和DAL之間共享數據對象是很常見的。有時，相同的數據對象也可以在UI層中使用。

通常我有一個數據模型（或數據對象或域模型，不管你怎麼命名）程序集，它將所有的模型對象作爲接口。以你的人爲例，我將在模型組件中創建一個IPeople接口。 DAL會將IPeople的一個實例返回給BL。 BL將使用這個實例，如果需要的話，在應用業務邏輯之後將其傳遞給UI層。

來源

2010-06-27 07:00:14 matrix

n層體系結構 - BLL，DAL和接口。什麼是最佳做法？

回答

相關問題