我正在使用Jeffrey Palermo描述的Onion Architecture设计ASP.NET MVC应用程序。
这是一个ASP.NET MVC 2.0项目，在这里我要求使用专用的 View 模型对所有 View 进行强类型化-我们不会将域模型传递给我们的 View 。我们正在使用AutoMapper进行翻译-AutoMapper被隔离在基础结构中，Web不知道或不在乎正在使用AutoMapper。
当前，我正在Web项目中定义IViewModelMapping接口(interface)-仅仅是因为该服务将由Controller使用，并且可以直接访问其自己的View Model。这样，界面就可以访问域模型(在Core中)和 View 模型(在Web中)。
为了提供IViewModelMapping接口(interface)的实际实现，我在基础结构项目中创建了一个ObjectMapping命名空间，该命名空间将把实际的映射实现隔离到洋葱的Intrastructure。为此，这将要求基础架构同时依赖Core和Web。
我的问题是:由于这两个项目在技术上都位于洋葱的郊区(在同一层中)，是否允许一个项目依赖于该层中的另一个项目？有人注意到这种设计有潜在的陷阱吗？
另一种设计是将IViewMapper接口(interface)移动到Core中-但这将是不可能的，因为Core无法访问ViewModel类。我也可以将 View 模型移到Core中，但是我觉得它们不属于Core模型，因为它们特定于UI层。
提议的体系结构如下-请注意，基础架构对Core AND Web具有依赖性。 Web保持隔离状态，只能访问Core业务逻辑。
http://www.matthidinger.com/images/onion-arch.png
最佳答案
您是正确的，您不希望基础结构依赖UI(Web)，但有时我会违反该规则。
我认为可以使用Map()方法创建IMapper，而不是IViewModelMapping。然后，接口(interface)可以具有可能与 View 模型映射有关的实现，或者可能只是常规映射。无论哪种方式，该接口(interface)都可以在Core中使用，因为它在语义上没有绑定(bind)到任何类型的模型。
很棒的图形。希望我回答了您的问题。 Onion体系结构的总体哲学是将业务逻辑和模型保持在应用程序的中间(核心)，并尽可能地将依赖关系向外扩展。