不了解在系统架构中创建IoC容器的位置

Question

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

1. Winforms UI
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容器通常应该在主机项目（应用程序入口点）中创建。对于作为exe项目的Windows.Forms应用程序。

通常在简单的解决方案（10个项目下）中，只有主机项目应该引用IoC库。

PS：Structuring .NET Applications with Autofac IoC

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更改为静态网关 - Abstracting IoC Container Behind a Singleton - Doing it wrong?