4

我的项目组织如下

  • ASP.NET MVC 3 Web 应用程序
  • Domain.Core - 接口 [库]
  • Domain.Core.Entity - 实体 [库]
  • Infrastructure.Core - 接口的实现 [库]
  • Infrastructure.IoC - 使用 Unity 作为实现控制反转的手段 [库]

困境如下：

如果我要向我的 Domain.Core 中的接口添加通用方法，如下所示，我会收到一个编译错误，要求我在 Infrastructure.IoC 项目中添加对 Domain.Core.Entity 的引用。

T Get<T>(int Id) where T : EntityBase, new();

T 可以是继承自 EntityBase 的类 EntityBase 或 Blog，也可以是其他一些都继承自 EntityBase 的实体。这个想法是根据提供的子类返回一个实体，以便子类加载所有实现 EntityBase 的类所需的默认数据。

所以，问题有两个方面：

  1. 在 IoC 项目中不引用 Domain.Core.Entity 项目并保持清洁会更好吗？

  2. 我将如何实现上述目标而不必弄乱参考文献的清洁度？

谢谢你。

注意：我在这里浏览了一些问题来搜索这个主题，但没有看到任何问题。如果您确实看到它，请告诉我，我将删除此问题。

4

2 回答 2

4

使用依赖注入，最好有一个组件负责组成所有不同的协作者。这是Nat Pryce 的Third-Party Connect概念中的第三方，或者我称之为Composition Root的东西。在上面概述的架构中，这个责任似乎落在了 Infrastructure.IoC 身上，因此，鉴于这种结构，将 Infrastructure.IoC 的引用添加到 Domain.Core.Entity 并没有错——事实上，如果这样做，我会觉得更令人惊讶并非如此。

然而，作为一个整体的反馈，我认为值得考虑拥有一个单独的 Infrastructure.IoC 库实际上会带来什么好处。该应用程序（ASP.NET MVC 应用程序）的入口点将需要对 Infrastructure.IoC 的引用，它必须再次引用所有库才能组合它们。因此，ASP.NET MVC 应用程序最终会间接引用所有其他库，您不妨合并这两个库。

（从技术上讲，您可以通过依赖某种后期绑定机制（例如 XML 配置或约定优于配置）来解耦各种库，但 Infrastructure.IoC 的概念责任将保持不变。）

有关更多信息，您可能需要阅读此答案：Ioc/DI - 为什么我必须在入口应用程序中引用所有层/组件？

于 2012-04-22T08:33:11.107 回答
3

为什么要从 Domain.Core.Entity 中拆分 Domain.Core？为什么要从 Infrastructure.IoC 中拆分 Infrastructure.Core？

我认为您可以摆脱 3 个项目结构：

  1. 域 - 不依赖于其他 2 个项目。可能包含实体和接口。
  2. 基础设施 - 包含接口实现和 Unity 容器。仅取决于域项目。
  3. MVC - 取决于域和基础设施。

如果您担心针对具体类而不是接口进行编程，请为基础设施项目中的类提供不同的命名空间。如果有的话，您应该只需要使用该命名空间几次（在 Global.asax 或引导程序中）。

这样就很清楚哪些项目依赖于什么。由于您使用的是统一，因此这是一种洋葱架构。如果您稍后发现应该将基础架构或域拆分为多个项目，则可以重构。

IMO，只有当您的域项目中有 System.Web.Mvc 或 Microsoft.Practices.Unity 之类的引用时，依赖项才会变得混乱或不干净。就像马克在他的回答中所说的那样，你的“洋葱”的外层将依赖于内层，你无法避免这种情况。但是尽量让该领域专注于其核心业务，尽可能避免在 UI 中如何使用它的细节。

于 2012-04-21T21:50:52.637 回答