问题标签 [onion-architecture]

我是否应该对如下所示的简单应用服务进行单元测试？

正如您所看到的，它只是接收一个视图模型，使用 AutoMapper 将其映射到域模型并调用域服务方法来更新对象。如果我应该对它进行单元测试，我正在努力查看单元测试的内容！这也许回答了我自己的问题，因为您可能会争辩说，除了 AutoMapper 的工作之外，没有什么可以测试的，我相信我不应该因为其他人的工作而进行单元测试，对吗？

编辑：感谢您的回复。我已经使用了类似这样的东西，它只是测试 UpdateInstance 方法被调用一次：

我已经按照Udi Dahan 的领域事件 - 拯救文章中的规定实现了领域事件。

据我了解，域事件可以与引发它的线程异步运行（通常来自域模型或服务）。

不需要任何类型的“共享”工作单元或存储库实现，也不需要事务一致性。

问题：为什么 Udi 没有在单独的线程中实现域事件的处理？

例如，我添加了一个Task异步处理事件的创建：

是否有任何可能由此产生的多线程问题？

编辑： 请注意，虽然这些域事件是轻量级的，但它们仍将在 IIS 上运行，因为这是一个 MVC Web 项目。

我是领域驱动设计的新手（我们有一个小伙子在推动我们使用它），我喜欢我所看到的。我了解洋葱架构，我相信它与 DDD 密切相关，但我不确定它如何与有界上下文一起工作。

在微软介绍中，我了解有界上下文的必要性

DDD 简介

但我不知道这些是不是单独的洋葱。似乎会有一些交叉，几乎就像里面有一个大洋葱和其他洋葱，这听起来很难实现。

洋葱架构第 1 部分

洋葱架构如何与有界上下文一起工作？

我正在尝试根据洋葱架构方法重构系统。

我的外层包括以下部分

1. WCF Web 服务（我们提供）

2. 数据库访问的基础设施类

3. 访问外部 Web 服务的基础结构类

4. 测试

我想仔细检查是否允许外层的不同部分相互依赖。例如，WCF 类可以直接依赖于基础结构程序集中的任何代码吗？

据我了解，这是不允许的。例如，WCF 代码应该只依赖于内层的代码（例如接口）。你能确认一下吗？

附言

我有点困惑，因为一方面有些文章证实了这一点：

您可能已经注意到我已经将橙色、黄色和蓝色的盒子分成了不同的集群。这是因为我仍然想应用 UI 组件不能依赖数据访问组件的旧规则，反之亦然。因此，我在这些组之间引入了隔板

但另一方面，测试（例如基础设施程序集中的代码）与基础设施程序集位于同一层并直接依赖于它们。

这是我第一次尝试实现洋葱架构。

1. 上面放置的文件夹是否正确？
2. DependencyResolution 项目的位置是否在 Domain 文件夹中？
3. 基础设施中的每个项目是否应该包含一个 DependencyRegistrar 文件，该文件将核心项目中的接口与它所包含的项目中的实现一起注册？
4. WebApi项目应该放在Presentation->Api中吗？是演示文稿吗？
5. 我应该将每个项目的所有单元测试放在“测试”文件夹中吗？

提前致谢。

我正在努力为我当前的项目获得一个好的架构。这是我第一次尝试使用软件工程的最佳实践（DI、单元测试等）来设计一个严肃的 n 层应用程序。我的项目使用的是洋葱架构。

我有4层

1. 核心层：它持有我的业务对象。在这里，我有代表我的业务实体的类及其方法。其中一些对象具有对服务接口的引用。

2. DAL（数据访问）层：它定义 POCO 对象并实现核心层中定义的存储库接口。在这一层中，我认为设计一个大型实用程序类是一个好主意，其作用是将 POCO 对象从 DAL 转换为来自核心的业务对象。

3. 服务层：它实现了核心中定义的服务接口。该层的作用是提供对 DAL 中定义的存储库的访问。我主要认为这个层没有用，所以我直接使用了核心层中定义的存储库接口。然而，在花了几个星期编写很长的实例化代码之后——让构造函数采用 5-6 个 IRepository 参数——我明白了服务层的意义。

4. 表示层。这里没什么特别要说的，只是我在这个层中配置了依赖注入（我使用的是 Ninject ）。

我已经更改了架构并至少重写了 3 次代码，因为很多时候我发现我的代码有问题。（例如带有长参数列表的长构造函数）。幸运的是，我对文献中发现的各种编码模式有所了解。

然而，我刚刚遇到了我的 DI 的周期性依赖，我很想知道我的 DAL2Core Helper 是否是个好主意......

感谢这个助手，我可以编写如下代码：

这减少了一点代码冗余。然后我在 DAL 中定义的每个存储库都有自己的 DAL2Core 成员：

我从 Repository 构造函数注入它。

DAL2Core 类本身有点混乱……首先，它对每个存储库和每个处理器（服务层）都有一个属性。处理器存在的原因是我的核心对象需要注入处理器依赖项。我将我的 DAL2Core 实用程序类中引用的一些存储库和处理器放在下面只是为了说明：

（由于存储库需要 DAL2Core Helper，因此构造函数注入会导致循环依赖）

然后这个类有很多简单的方法，例如：

这个类就像60000行。想一想，我意识到我并没有节省太多代码，因为很多时候 DAL2Core 转换代码只从一个地方调用，所以也许最好将此代码留在存储库中？而且 - 最大的问题 - 因为我决定将此帮助程序与我的存储库类分离，所以 Ninject 会抛出周期性依赖异常。

您如何看待我尝试的设计，这是一种好的/常见的做法吗？以及我怎样才能巧妙而有效地执行此 DAL2Core 转换而不会产生代码异味。我真的很期待解决这个架构问题，过去三周我一直在处理管道和架构问题，并没有真正推进那个项目。我变得很晚了。但是我真的很想生成高质量的代码。我只是想避免对我来说看起来有点矫枉过正的架构解决方案，有很多工厂等......但我承认有时，这种感觉只是来自我缺乏理解（比如服务层）。

在此先感谢您的帮助 ！

我的项目有一个设计问题，我不知道如何解决，我有一个包含存储库的 DAL 层和一个包含“处理器”的服务层。处理器的作用是提供对 DAL 数据的访问并执行一些验证和格式化逻辑。

我的域对象都引用了服务层中的至少一个对象（以从存储库中检索它们的属性值）。但是我面临两个周期性依赖。第一个“循环依赖”来自我的设计，因为我希望我的 DAL 返回域对象——我的意思是它是概念性的——第二个来自我的代码。

1. 一个领域对象总是依赖于至少一个服务对象
2. 域对象通过调用服务上的方法从存储库中检索他的属性
3. 服务的方法调用 DAL
4. 然而——问题是——当 DAL 完成他的工作时，他必须返回域对象。但是要创建这些对象，他必须注入所需的服务对象依赖项（因为域对象需要这些依赖项）。
5. 因此，我的 DAL 存储库依赖于服务对象。

这导致了非常明显的周期性依赖。我对如何处理这种情况感到困惑。最后，我正在考虑让我的 DAL 返回 DTO，但它似乎与洋葱架构不兼容。因为 DTO 是在 Infrastructure 中定义的，但 Core 和 Service Layer 不应该知道 Infrastucture。

此外，我对更改存储库中所有方法的返回类型并不感到兴奋，因为我有数百行代码......

我将不胜感激任何帮助，谢谢！

更新

这是我的代码，可以使情况更清楚：

我的对象（在核心）：

这是我的服务接口（在核心）

这是我的存储库接口（在核心中）

现在服务层实现了 IService，DAL 层实现了 IRepoComplexClass1。

但我的观点是，在我的仓库中，我需要构建我的域对象

这是基础设施层

我希望现在更清楚了。

我一直在阅读洋葱架构，今天我发现了鲍勃叔叔的清洁架构。

对于我的生活，我看不出它们之间有任何区别，它们看起来相同（命名约定除外）。

两种建筑风格有什么区别吗？如果是的话，你能给我解释一下吗？

干杯

我正在尝试遵循 OWIN/Katana 上托管的 WebAPI 服务的洋葱架构。

我有一个这样的解决方案结构：

• DependencyResolution：包含 OWIN 启动类和 IoC 设置
• WebApi：Web API 控制器
• 基础设施：接口实现
• 核心：接口

我希望 DependencyResolution 项目为 WebApi 项目注入依赖项。DependencyResolution 确实有一个构建任务来输出到 WebApi 项目的输出文件夹。

我正在遵循此处概述的方法，使用 Autofac 和 DotNetDoodle.Owin.Dependencies NuGet 包：

http://www.tugberkugurlu.com/archive/owin-dependencies--an-ioc-container-adapter-into-owin-pipeline

但是，在我的 Startup 类中注册服务时，对 RegisterApiControllers() 的调用将失败。DependedencyResolution 程序集将首先执行，因此它将无法获取包含 ApiContollers 的程序集（WebAPI 程序集）：

诉诸 Assembly.Load() 是这里唯一可行的选择，还是我应该放弃保持 DependencyResolution 项目隔离的想法，而只是从 WebApi 项目中引用它（似乎比洋葱少一点）？

我正在尝试将它们组合在一起，为现有应用程序构建一个新架构。现有应用程序有很多业务逻辑，所以我认为 Onion 架构（或类似的东西 - 分层、解耦）可能是正确的解决方案 - http://jeffreypalermo.com/blog/the-onion-architecture-part-1 /

我看到的所有示例都在基础设施层（或 DAL，或任何实际连接到数据库的层）中使用 Repo/UoW（顶部或 ORM）模式。但我不确定在我的情况下 Repo/UoW（在 EF 之上）是否必要，因为：

• EF6 可以在没有 Repo 模式的情况下很好地进行单元测试，并像这样实现有界 DbContexts - http://msdn.microsoft.com/en-us/library/dn314429.aspx

• 大多数 Generic Repo 示例倾向于使用泄漏抽象，因为它们公开了接受 LINQ 查询的方法（如 Expression> query）

• 非泛型 Repos 往往会导致大量代码

所以这里有几个问题：

1）大多数示例首先使用EF代码，核心层使用POCO对象，但我必须先使用数据库并生成模型。我可以在 Core 中使用 EF 生成的 .edmx 模型，还是这会对数据访问造成不必要的耦合？有没有办法从 EF 生成的数据访问代码（context.tt 文件等）中拆分 EF 生成的类（带有表字段的 .cs 文件）？

2）我打算像这样实现服务层（有界的 DbContext 接口作为依赖项传递）

这意味着，将有 DbContext 与 DbSet 的包装器接口，而不是存储库接口。可以使用模拟 IMyDbContext 和模拟 IDataSet 来完成单元测试。这不是打败了抽象数据库的整个概念吗？在我看来，这对于单元测试来说已经足够了，但是从架构的角度来看这可以吗？我是否错过了 Repo/UoW（在 EF 之上）模式提供的一些很棒的功能？

3）似乎存储库的一种替代方案（虽然不是很受欢迎）是查询对象： http ://www.wekeroad.com/2014/03/04/repositories-and-unitofwork-are-not-a-good-idea /

http://lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/

但我还没有真正找到 Onion + Query Objects 的任何示例。这可能是 Repository 接口层的合理选择吗？将查询接口放在那里，而将查询实现放在接口（数据访问）层？我应该将所有数据访问逻辑放在 QueryObjects 中吗？如果我直接在 Coltroller/Service 层中使用 DbContext.Where 查询，这是否会在数据访问和业务逻辑之间产生不必要的耦合？