不了解在系统架构中的何处创建 IoC 容器

Question

假设我有以下 4 个 .net 程序集：

1. Winform用户界面
2. 商业逻辑
3. SQL Server 数据访问（实现 IRepository）
4. 通用接口（IRepository等的定义）

我的业务逻辑 (2) 使用构造函数依赖注入通过 IRepository（在 4 中定义）调用数据访问层 (3)。然而，当我创建一个业务对象时，我需要传递一个实际的存储库。我通过在业务逻辑层中使用一个单例类返回当前使用的实现 IRepository 的具体对象来实现此目的。我得出的结论是，这是一件坏事，因为我的业务逻辑层现在必须引用 3 和 4。

我想我需要一个 IoC 容器，但问题是我在哪里创建/放置它，因为看起来我在哪里创建这个（1 - UI）？还需要保留对 3（SQL Server 数据访问）的引用。难道我只是转移问题而不是实现真正的解耦吗？

我是否在 UI 中创建 IoC 容器。或者通过另一个新程序集公开它。

（我使用 C#、.net 3.5 和 AutoFac）

谢谢。

Answer 1

IoC容器一般应该创建在 宿主项目 （应用程序入口点）。对于 Windows.Forms 应用程序来说，这是 exe 项目。

一般来说，在简单的解决方案（10 个项目以下）中，只有一个宿主项目应该引用 IoC 库。

附： 使用 Autofac IoC 构建 .NET 应用程序

Answer 2

注册组件时有几种可能性：

1. 注册码：

   • 直接地
     问题：你必须参考一切（你在这里）
   • 间接地
     问题 ：找出必须注册的内容
     解决方案：
     1. 使用属性
     2. 使用标记接口作为 IService
     3. 使用约定（参见 StructureMap）

2. 使用配置文件注册：

   • 让容器做一切
   • 自己阅读文件

Answer 3

顶级是一条路要走（UI，正如 Rinat 所说）。

现在对于引用，最简单的方法就是遍历当前文件夹中的所有程序集并使用一些约定来获取服务。属性工作正常，将注册器类放入每个程序集中工作正常，无论适合您什么。提取所有内容的代码可能应该位于单独的程序集中，除非您的 IoC 框架已经这样做了。

Answer 4

模块区别和模块定义的“范围”主要存在于编译时。在运行时，这一切都是一团乱；）这是大多数 IOC 容器使用的，它们并不真正关心它们所在的位置。Web 应用程序的 IoC 容器通常在最外层创建（非常接近 Web 容器本身）。

Answer 5

确实，您可以在任何地方创建它，但我会引入一个额外的层，我们将其称为 3.5。

您当前的 3 将是 IoC 驻留在数据访问的位置 - 这将成为您实际 DAL 的包装器。根据您的配置，3 将创建一个模拟存储库或一个具体存储库。

因此 2 仍然引用 3，但它只是通过 IoC 框架配置的实际 DAL 的接口。

或者，您可以推出自己的“el-cheapo”IoC - 将您的 Big Ugly Singleton 更改为静态网关 - 在单例背后抽象 IoC 容器 - 做错了吗？