以上是描绘我对洋葱建筑的理解的两幅图像 . 它们与在线发现的图纸略有不同，因为它们解决了我无法找到答案的议程 .
据我所知，基础设施是持久性，日志记录等等 . 我用斜体字写了它们的例子 . 但是，很多时候，基础架构组件以及UI往往需要彼此通信 . UI可能想要审核或记录某些内容，持久性项目可能需要记录某些内容 . 记录是洋葱建筑中难以适应的物品之一，我的理解是很多人对你应该和不应该记录的地方有不同的看法 .
在我的第一张图中，我在图中放置了一个Infrastructure Interfaces层，以允许交叉通信，而没有任何一个组件知道另一个组件的实现 . 这是我在一些例子中看到的 .
第二张图是我的偏好，它使用中介来交叉基础设施，UI之间的通信，它基本上是一种允许核心服务间接与基础设施通信的方式（假设服务接口在右图中称为核心服务） . Logger 会订阅某些事件，数据库等也是如此 .
第一个图仅允许除外层（不包括依赖项解析程序）之外的所有层中的pocos和接口 . 第二个允许核心服务层中的域和业务逻辑，并允许基础结构层单独执行其工作 .
我通过确保它们具有某种类型的输出来证明基础架构组件的合理性 . 审计和日志记录通常会使用某种类型的数据库，缓存通常存储在内存中，而数据库可能应该被称为持久性 . 但是，有一个名为AutoMapper的库 . 我已经看到它包含在某些实例中，因此它的接口可以在Core中用于几乎任何基础结构，但它似乎过度抽象给我 . Automapper有点像Events对象，因为所有基础结构都使用它来在自身和域之间进行转换，但我不确定它是否适合该层，因为它不是服务 .
Question: Which of the two is closest to the definition of onion architecture and where would you fit in a tool like auto mapper, and do you think trying to wrap something like that is over abstraction?
谢谢！
1 回答
我使用过Auto Mapper和洋葱架构 . 我们在MVC Global.asax文件中配置了AutoMapper，该文件通常在App Start目录的AutoMapperConfig类中调用Config Method .
关于您的图形，它们中的一个显示了Mediator和Observer Patters的单独图层 . 它们不一定是必需的，但完全取决于您的方法 . 就像您可以在洋葱架构或模型 - 视图 - 展示器或模型 - 视图 - 视图模型中使用模型 - 视图 - 控制器模式一样 . 他们只是将单独的模式结合起来，以包含一些额外的好处 .
这是我第一次遇到the Onion Architecture Jeffery Palermo的地方 . 如果您想要看到更纯粹的图形表示 .