2009-01-27 62 views
7

我有一個3層.NET服務的應用程序,它遵循的標準方法:n層應用程序中的依賴注入?

Frontend -> Object Model/Business Logic -> Data Access 

我想了解沿途依賴注入,因此到目前爲止已經發現了它巨大的(使用Autofac) 。 3層中的每一層都需要創建各種對象,有時還需要額外的配置/等等。似乎DI容器應該是解決這個問題的理想工具,但是我有一些問題要看它應該與系統的其他部分相連。

目前我在配置DI容器的前端有一個類。它基本上是一大堆代碼,說container.Register<SomeType>()等等。

問題是,它正在爲所有3層配置容器,因此必須具有對數據訪問層的相當侵入性的知識。在我的前臺使用這些知識代碼在我的腦海中引發了警鐘,因爲將應用程序分成多個層級的目的是爲了避免這種情況。
由於我的數據訪問層不僅僅是SQL服務器,而且是由大量複雜的COM互操作和P/Invoke調用組成的,因此這也會變得更糟。 DI配置。我已經給出了一些想法來打破它 - 也許每層有一個容器,或在每層中有一個「安裝」類與全球DI容器進行對話以註冊它自己的位,但我不確定如果這會導致更多的問題比它解決...

我真的很感激,如果任何人都可以分享他們的經驗,使用DI多層應用程序。

謝謝,獵戶座。

+0

你有沒有類似於服務層的東西?以便您的前端在Business Objects之前與其交互。 – BuddyJoe 2009-01-27 22:08:55

回答

2

這取決於您是否有三層(物理分離)或者所有邏輯層都一起部署。如果前端與BL分離並通過Web服務或WCF通信,則前端和後端需要自己的容器,因爲它們在單獨的進程或單獨的機器中運行。容器只會註冊自己的組件和「下一個」層的接口。

另一方面,如果所有圖層都在同一個進程中運行,那麼您應該只有一個容器。該容器將被初始化並託管在應用程序的起始點,如用於Web應用程序的global.asax。

容器主機知道系統的所有不同部分的問題可以通過不逐一註冊類來解決,而是在一個程序集中註冊所有類型。這樣你就不需要對解決方案中所有組件的強引用來配置容器。 Castle Winsdor如何做到這一點的例子:

Kernel.Register(AllTypes.Pick().FromAssemblyName("DataAccessLayer.dll")); 
Kernel.Register(AllTypes.Pick().FromAssemblyName("BusinessLogic.dll"));