问题标签 [onion-architecture]

我的领域层中有一些非常昂贵的业务逻辑，必须在其中跟踪数据，以便了解发生故障时会发生什么。正因为如此，我想声明一个简单的日志接口：

现在我的问题是——这个接口属于哪里？当然，日志记录可能是一个基础设施问题（以及一点跨层问题），但如果我将它放在基础设施层，我的域服务将无法访问它。如果放到域层，我引入了登录到我的域的概念，感觉很别扭。

我已经在我的应用程序中使用了来自 CQRS 和 EventSourcing 的某些概念，但是为域服务中的数据发生的所有事情抛出一个事件似乎是一种矫枉过正（尤其是如果数据处于无法返回的状态）由域服务直到进行了进一步的转换。）

我首先使用 Entity Framework 6 数据库。我正在将项目转换为实现洋葱架构，以实现更好的关注点分离。我阅读了许多文章并观看了许多视频，但在决定我的解决方案结构时遇到了一些问题。

我有 4 个项目：核心、基础设施、Web 和测试。

据我所知，.edmx 文件应该放在我的“基础设施”文件夹下。但是，我还阅读了有关使用存储库和工作单元模式来协助 EF 解耦和使用依赖注入的信息。

话虽如此：

• 我是否必须在 CORE 下为模型中的所有实体创建存储库接口？如果是这样，如何在一个巨大的数据库上维护它？我研究了 automapper，但发现它在呈现 IEnumererables 与 IQueryables 时存在问题，但有一个可用的扩展程序必须解决这个问题。我可以更深入地尝试这条路线，但想先收到回复。

• 作为替代方案，我是否应该将我的 edmx 留在 Infrastructure 中并将我的实体的 .tt T4 文件移动到 CORE？这是否提供了任何紧密耦合或一个好的解决方案？

• 通用存储库接口是否可以很好地配合您提供的建议？或者，也许 EF6 已经解决了存储库和 UoW 模式问题？

感谢您查看我的问题，并请提供任何替代答复。

我在这里找到了一个类似的帖子，但没有得到回答： EF6 and Onion architecture - database first and without Repository pattern

我试图掌握洋葱架构的重要概念，并且在阅读一篇文章后问自己一个问题。查看此图像中显示的架构中的域：http ://tonysneed.files.wordpress.com/2011/10/onion-proj.jpg?w=282&h=494

将 Domain.Entities 和 Domain.Interfaces 分隔在两个单独的项目中而不是让一个 Domain 项目具有实体和 Interfaces 文件夹的实用性是什么？我不是很有经验，但我没有看到有人会感谢上帝他将域实体和域接口分开的场景..

在将 Onion Architecture 与Windows Forms UI 层相结合时，我遇到了障碍。问题是我的IoC配置方法永远不会被命中。IoC 设置发生在依赖解析程序集中：

而且我希望我的 UI 层除了Project.Core.

在我使用此架构的 Web 项目中，我使用了 WebActivatorEx 和 OutputTo 来引导我的 IoC。因为我很熟悉，所以我决定在这里使用相同的，但它的行为不像预期的那样。我不确定我是问题还是 Windows 窗体是问题所以这是我的设置：

在 Project.DependencyResolution 中：

OutputTo 的 OutputTargets.txt：

在 Project.UI 中：

OutputToDependencyResolution's将 DLL 文件正确复制到Ui'sbin，但从IocConfig.RegisterDependencies不运行。

那么如何从它自己的程序集中设置 IoC，其中 Windows 窗体项目是启动项目？

我正在尝试在遵循洋葱架构的 ASP.NET MVC 5 解决方案中实现 Identity 2.0。

我有一个ApplicationUser在我的核心。

在我的数据访问层中，我使用的是 Entity Framework 6.1，而我的上下文来源于IdentityDbContext问题所在。ApplicationUser需要从Microsoft.AspNet.Identity.EntityFramework.IdentityUser

我的域模型不应该引用Microsoft.AspNet.Identity.EntityFramework会违背洋葱的想法。

什么是好的解决方案？

在我的项目中，我有一个操作存储库的服务层。服务层由我的控制器调用。

在许多情况下，我的控制器层能够在传入信息进一步进入系统之前对其进行验证。但是，在某些情况下，由于提交的数据无效，可能会出现错误，但仅在我的服务层内的某个点上。

考虑到这一点，假设我正在做一个用户注册流程：

• 不允许重复的用户名
• 可以提供用户名
  • 如果未提供用户名，则从名字和姓氏生成

这意味着生成（如有必要）和检查重复用户名的过程在服务层进行。

如果出现重复，我向调用者（无论是控制器、后台任务还是其他服务）发出信号的最解耦和最理想的方式是什么 - 即：

• 用户名字段有问题
• 如果适用，生成的用户名

理想情况下，建议的方法将能够应用于其他服务中发生的错误，以便我可以提出一致的报告方式，从而处理调用层中的错误。

洋葱架构模型

上面两张图片描述了我对洋葱架构的理解。它们与网上找到的图纸略有不同，因为它们解决了我找不到答案的议程。

据我所知，基础设施是诸如持久性、日志记录等之类的东西。我已经用斜体写了它们的示例。然而，很多时候，基础设施组件以及 UI 往往需要相互通信。UI 可能想要审计或记录一些东西，持久性项目可能需要记录一些东西。日志是洋葱架构中最难适应的项目之一，我的理解是，很多人对应该在哪里登录和不应该在哪里登录有不同的看法。

在我的第一幅图中，我在图表中放置了一个基础设施接口层，以允许在没有任何一个组件知道另一个组件的实现的情况下进行交叉通信。这是我在几个例子中看到的。

第二张图是我的偏好，它使用中介在基础设施、UI 之间进行交叉通信，它基本上是一种允许核心服务与基础设施间接通信的方式（假设服务接口在右图中称为核心服务）。记录器将自己订阅某些事件，数据库等也是如此。

第一个图只允许除外层（不包括依赖解析器）的所有层中的 pocos 和接口。第二个允许核心服务层中的域和业务逻辑，并允许基础设施层独立地完成工作。

我通过确保它们具有某种输出来证明基础设施组件的合理性。审计和日志记录通常会使用某种数据库，缓存通常会存储在内存中，而数据库可能应该被称为持久性。但是，有一个名为 AutoMapper 的库。我已经看到它在某些情况下被包装，因此它的接口可以进入核心以用于几乎任何基础设施，但对我来说似乎过于抽象。Automapper 有点像 Events 对象，因为所有基础设施都使用它在自身和域之间进行转换，但我不确定它是否适合该层，因为它不是服务。

问题：两者中哪一个最接近洋葱架构的定义，你会在哪里使用像自动映射器这样的工具，你认为尝试包装这样的东西是否过于抽象？

谢谢！

1）根据域驱动设计，域层应该只有存储库接口，实现不应该是域层的一部分 - 如果我的理解有误，请告诉我？

2）如果存储库实现不应该是域层的一部分，那么我应该将存储库实现保存在哪里（在基础设施中？）

3）如果我想有这样的设计流程，以下目录结构是否可行：（我使用的是DAO而不是ORM）

控制器 <---dto---> 域服务 <----dto---> RepositoryImpl <---> DAOImpl

4) 存储库可以是数据访问层的一部分吗？

5) DDD 是架构还是设计？如果是架构，那么 DDD 和洋葱架构有什么区别？

我正在尝试遵循最佳实践并确保我的控制器倾向于在服务层中执行主要业务逻辑的位置。

在下面的操作中，我已将验证登录代码提取到服务层，但不确定处理 HttpConext.GetOwinContext.Authentication 并创建声明身份的逻辑应该去哪里？

这个控制器操作中的代码似乎太多了，还是可以保留在这里？它应该留在控制器中还是被提取到自己的服务基础设施或某种静态类中？

我对这将在哪里或它持有什么感到有点困惑。

我正在尝试遵循洋葱架构http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

我正在尝试学习洋葱架构，据我所知，我将我的解决方案组织如下：

领域

• Domain.Entities（业务对象）
• Domain.Interfaces（域服务和存储库的接口）
• Domain.Services（领域服务接口的实现）

基础设施

• Infrastructure.Data（使用 EF 实现存储库和工作单元）
• Infrastructure.DependencyResolution（使用 Unity 实现 IoC）

用户界面

• UI.WebMVC

这是我的问题：

1-我对这些层是正确的还是我错过了什么？

2- 至于与特定技术（例如日志记录）相关的服务，它们的接口应该在哪里（Domain.Interfaces 或 Infrastructure.Interfaces）？

3- 据我了解，域服务将处理我的业务用例，那么我将从应用程序服务中获得什么好处

4-域服务和应用服务有什么区别，应用服务接口应该在哪个项目中？

5- 用户授权过程应该是应用程序服务或域服务的一部分吗？