MODEL和BLL之間的循環依賴關係

假設一個架構如此。MODEL和BLL之間的循環依賴關係

MODEL > BLL > DLL

試圖實現延遲加載在我的模型我遇到了我的模型和BLL之間的循環依賴..

基本上想象在我的模型的屬性，我想實現如下

Public Readonly Property ProjectCategory As ProjectCategory 
    Get 
     If Me._ProjectCategory Is Nothing Then 
      Me._ProjectCategory = ProjectCategoryBLL.GetProjectCategoryByID(Me._ProjectCategoryID) 
     End If 

     Return Me._ProjectCategory 
    End Get 
End Property

我有我的模型，BLL和DLL在單獨的項目中，因爲我的BLL引用我的模型的事實，我不能從我的模型中引用我的BLL，因爲這會創建一個循環依賴項。

這個問題的典型解決方案是什麼？

來源

2011-09-01 Maxim Gershkovich

如果他們是如此緊密地在不同的組件加上爲什麼讓他們？ –

有效的觀點......自己一直在思考這些問題。 –

它看起來像你有可怕的混合起來的事情，最有可能是由於層次和模式的混合瞭解。

爲什麼你的BLL引用你的模型？它應該沒有必要。在經典的n層應用程序中，模型和BLL是同一件事。如果你繼續爲你的UI實現一個模式（比如MVVM），那麼這個模型可能仍然是BLL，或者它可能是一個單獨的代碼，它調用BLL（並且BLL沒有直接瞭解模型）。在MVC中，模型處理數據，因此它再次與BLL交談（或者甚至可能被集成並且是BLL的一部分）。

我的建議是模型引用BLL，但不是相反。或者，您可以將模型整合到BLL中，具體取決於您正在構建的複雜性。

來源

2011-09-01 03:28:19 slugster

「爲什麼您的BLL引用您的模型？它應該沒有必要」 - Microsoft最佳實踐n層示例：http://download.microsoft.com/download/8/0/1/801ff297-aea6-46b9-8e11 -810df5df1032/Microsoft％20.NET％20Pet％20Shop％204.0.msi BLL參考模型 –

Mmmmkay ....我不打算下載，只是爲了檢查，我會接受你的話。但僅僅指出這一點並不能回答我的問題：*爲什麼BLL **需要**來引用模型？*模型的工作是將數據傳入或傳出BLL，並且他們經常可以是相同的東西（相同的組件）。如果他們是分開的，那麼BLL應該不知道使用它的組件是什麼，它應該只是做它的生意。 – slugster

對不起，不排除你的觀點，絕對同意你所說的其他內容......然而，正如你指出的那樣，在鏈接2的例子中，沒有關於模型中BLL的知識。 –

您可以爲您的Model項目中引用的bll類創建接口，並使用工廠模式或使用依賴注入創建具體類。只是準備給你的項目增加一些複雜性。另一種方法是查看ORM。他們照顧很多懶惰加載的屬性，看起來像你試圖實現

來源

2011-09-01 04:05:01 clyc

我不贊成你當前的架構。當然，將應用程序分層爲邏輯或物理層取決於您的項目需求和複雜性。但是這將是一個更好的主意來擺脫當前的實施和應用新的架構，例如：

域模型：由你的域實體，接口爲您的存儲庫等
存儲庫：實現在域模型中定義的存儲庫協定，您可以有不同的存儲庫實現。
AppService：由View Models,Messages,Application Services等組成。這將成爲用戶進入整個系統的切入點。
演示文稿：將執行一個演示模式，如MVP或MVC模式。

這將是分層應用程序的通用架構。嘗試針對接口而不是具體實現進行編程。此外，您抽象業務組件（應用程序層）的次數越多，利用使用Design Patterns和最佳實踐的優勢的次數越多，確保您的代碼庫將更具可伸縮性，鬆散耦合性和更好的可維護性。

如果你正在開發一個產品，而不只是示例應用程序爲你自己，我建議你挖得更深一些，到Domain-Driven Design，Enterprise Application Architectures和Design Patterns到能夠模擬自己的業務需求，並實現更好，更穩健建築。如果您需要了解更多信息或具體問題

將很樂意談論這個[：

來源

2011-09-01 04:15:24 Nexus

MODEL和BLL之間的循環依賴關係

回答

相關問題