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 回答