我正在使用Jeffrey Palermo描述的Onion Architecture设计ASP.NET MVC应用程序。
这是一个ASP.NET MVC 2.0项目，我要求所有视图都使用专用的视图模型进行强类型化 - 我们不会将域模型传递给我们的视图。我们使用AutoMapper进行翻译 - AutoMapper在基础架构中被隔离，Web不知道或不关心AutoMapper的使用。
目前，我正在Web项目中定义IViewModelMapping接口 - 只是因为控制器将使用此服务，并且它可以直接访问自己的View Models。这样，界面可以访问域模型（在Core中）和View模型（在Web中）。
为了提供IViewModelMapping接口的实际实现，我在Infrastructure项目中创建了一个ObjectMapping命名空间，它将实际的映射实现与洋葱的Intrastructure隔离开来。这样做，这将要求Infrastructure依赖于BOTH Core AND Web。
我的问题是：由于这两个项目在技术上位于洋葱的郊区（在同一层中） - 是否允许一个项目依赖于该层中的另一个项目？有没有人注意到这种设计有任何潜在的缺陷？
另一种设计是将IViewMapper接口移动到Core中 - 但这是不可能的，因为Core无法访问ViewModel类。我也可以将视图模型移动到Core中，但我觉得它们不属于那里，因为它们特定于UI层。
建议的架构如下 - 请注意，基础架构依赖于Core和Web。 Web仍然是孤立的，只能访问核心业务逻辑。
答案 0 :(得分：27)
你是不对的，你不希望基础设施依赖于UI（Web），但我有时会打破这个规则。
我认为不是使用IViewModelMapping，而是使用方法Map（）创建IMapper。然后，接口可以具有可能与视图模型映射有关的实现，或者可能只是常规映射。无论哪种方式，该接口都可以在Core中，因为它在语义上不绑定到任何类型的模型。
伟大的图形。我希望我能回答你的问题。洋葱架构的整体理念是将您的业务逻辑和模型保持在应用程序的中间（核心），并尽可能向外推送您的依赖项。
答案 1 :(得分：0)
尝试将对象映射移动到 Web 层。
答案 2 :(得分：0)
您的Web / UI层可以依赖于Infrastructure层。但是，在基础架构层上依赖Web并不是一个好的设计。洋葱架构说尽可能向外推动你的依赖。
你可以创建一个＆＃34; \ Builder＆＃34; UI中的文件夹。在其中添加一个接口文件，例如.. IBuilder或IMapper，并在其中声明类似ConvertToViewModel或CreateMapping的方法。无论你喜欢什么。
*生成器 ** IBuilder.cs -declare这里的方法。 ** Builder.cs - - 在此实现方法，定义ViewModel与其对应的DomainModel（来自核心层的引用）之间的映射，并在此返回适当的ViewModel。
