洋蔥archicecture依賴關係：基礎設施和網絡通信

Question

我設計使用由傑弗裏·巴勒莫描述的Onion Architecture ASP.NET MVC應用程序。

這是一個ASP.NET MVC 2.0項目中，我要求所有的視圖中使用專用的視圖模型是強類型的 - 我們不會通過域模型對我們的看法。我們使用AutoMapper進行翻譯 - AutoMapper在基礎架構中是孤立的，Web不知道或在意使用AutoMapper。

目前，我定義Web項目的IViewModelMapping接口 - 僅僅是因爲該服務將通過控制器一起使用，它有它自己的視圖模型的直接訪問。這樣接口就可以訪問域模型（Core）和視圖模型（Web）。

爲了提供IViewModelMapping接口的實際實現，我在基礎結構項目中創建了一個ObjectMapping命名空間，它將實際的映射實現與洋蔥的基礎設施隔離。在這樣做的時候，這需要基礎架構依賴於核心和網絡。

我的問題是：因爲這兩個項目在技術上對洋蔥的郊區（在同一層） - 是一個項目允許對在該層其他項目的依賴？有沒有人注意到這個設計有任何潛在的缺陷？

另一種設計將是IViewMapper接口移動到核心 - 但這是不可能的，因爲核心不具有訪問視圖模型類。我也可以將視圖模型移動到Core中，但我覺得他們不屬於那裏，因爲它們是特定於UI層的。

建議的體系結構如下所示 - 請注意，基礎結構對Core和Web具有依賴性。 Web仍然是孤立的，只能訪問Core業務邏輯。

http://www.matthidinger.com/images/onion-arch.png

Answer 1

你是正確的，你不想基礎設施依賴於UI（網頁），但我有時會打破這個規則。

我會想，而不是IViewModelMapping，用方法Map（）創建IMapper。然後，該接口可能具有可能與視圖模型映射有關的實現，或者可能只是定期映射。無論哪種方式，該接口可以在Core中，因爲它沒有語義綁定到任何類型的模型。

偉大的圖形。我希望我回答你的問題。洋蔥體系結構的整體理念是將您的業務邏輯和模型保留在應用程序的中間（核心），並儘可能向外推送您的依賴關係。

Answer 2

試着移動對象映射分成Web層。

Answer 3

您的Web/UI層可以依賴於基礎架構層。但是，在基礎架構層上依賴Web是不太好的設計。洋蔥建築表示儘可能向外推動你的依賴。

您可以在UI中創建一個「\ Builder」文件夾。在其中添加一個接口文件，例如.. IBuilder或IMapper，並在其中聲明一個類似ConvertToViewModel或CreateMapping的方法。隨你喜歡。

* Builder中 ** IBuilder.cs這裏-declare的方法。 ** Builder.cs - - 在此實現此方法，定義ViewModel與其對應的DomainModel（核心層引用）之間的映射，並在此處返回適當的ViewModel。