asp.net-mvc-3 - IoC 的泛型关注点分离

Question

我的项目组织如下

ASP.NET MVC 3 Web 应用程序

Domain.Core - 接口(interface) [库]

Domain.Core.Entity - 实体 [库]

Infrastructure.Core - 接口(interface)的实现 [库]

Infrastructure.IoC - 使用 Unity 作为实现控制反转的一种手段 [库]

困境如下:

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

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

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

所以，问题有两个方面:

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

我将如何实现上述目标而不必弄乱引用文献的清洁度？

谢谢你。

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

Answer 1

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

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

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

有关更多信息，您可能需要阅读此答案:Ioc/DI - Why do I have to reference all layers/assemblies in entry application?