2011-09-01 97 views
0

假設一個架構如此。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,因爲這會創建一個循環依賴項。

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

+0

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

+0

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

回答

1

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

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

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

+0

「爲什麼您的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參考模型 –

+0

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

+0

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

0

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

0

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

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

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

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

將很樂意談論這個[: