使用抽象工廠或部分類的二元選擇

我正在用實體框架模型優先方法構建CRUD應用程序。我的應用程序的構造方式是UI LAYER和DAL都依賴於域圖層，並且域圖層不依賴於任何內容。域層僅公開存儲庫和域對象接口。該存儲庫在DAL中實現並通過依賴注入提供給域層。作爲所有存儲庫，我的存儲庫公開了像getCustomer，deleteCustomer等函數，但由於這些函數是在DAL中實現的，因此DAL必須能夠創建符合Domain層中接口的對象。現在我的二元選擇是我應該如何讓它這樣做：我應該使用抽象工廠並將它們注入到DAL中，或者擴展部分生成的實體的定義並使它們實現由域層公開的接口？使用抽象工廠或部分類的二元選擇

來源

2012-11-28 Ibrahim Najjar

您是否期待有人在未來某個時候換出您的DAL？爲什麼DI？在我看來，你正在過度複雜的解決方案。 – Heather

@ Heather，實際上沒有過度複雜。只是設計正確的方式。在使用任何工具之前，DI完全遵循良好的原則。 –

域層僅公開存儲庫和域對象接口。

在這種類型或體系結構（hexagonal architecture）中，域對象不應該有接口，只有存儲庫。相反，讓DAL直接創建（重建）域對象。將域對象抽象爲接口沒有任何好處，只有不必要的複雜性，比如工廠。另外，正如Heather所指出的那樣，抽象存儲庫通常也是不必要的複雜性。在實現中製作真正可移植的存儲庫抽象幾乎總是徒勞的。在我看來，存儲庫抽象的核心優勢在於可以在沒有接口的情況下實現封裝 - 僅僅直接引用實現類。

來源

2012-11-28 23:53:04 eulerfx

測試如何？當我設計一個倉庫時，我總是從需要倉庫的界面開始。在定義域對象之後，我在項目後期實施回購。 DAL的實施是我做的最後一件事。 – MikeSW

說實話，你描述的是我的默認方法。但是，這也可以通過讓您的存儲庫類實質上是一個存根來完成。另一種方法是用模擬框架來模擬存儲庫對象。從組織的角度來看，存儲庫接口可能很好，因爲它定義了存儲庫的合同。但我有時認爲爲測試創建一個接口是不必要的。 – eulerfx

我必須說，除了知識庫部分，我同意你說的大部分內容。所以我批准了答案。 –

使用抽象工廠或部分類的二元選擇

回答

相關問題