假设我有以下4个.net程序集：
我的业务逻辑（2）使用构造函数依赖注入通过IRepository（在4中定义）调用数据访问层（3）。但是，当我停止业务对象时，我需要传入一个实际的存储库。我通过在业务逻辑层中使用单例类返回实现IRepository的当前使用的具体对象来实现此目的。我得出的结论是，这是一件坏事，因为我的业务逻辑层现在必须引用3和4。
我想我需要一个IoC容器，但问题是我在哪里创建/放置它似乎无论我在哪里创建它（1-UI）？还需要保存对3（SQL Server数据访问）的引用。我不是只是解决问题而不是实现实际的脱钩吗？
我是否在UI中创建IoC容器。或者通过另一个新组件暴露它。
（我正在使用C＃，。net 3.5和AutoFac）
谢谢。
通常应该在IoC容器中创建 主持人项目 （申请入境点）。对于作为exe项目的Windows.Forms应用程序。
通常在简单的解决方案（10个项目下）中，只有主机项目应该引用IoC库。
通常应该在IoC容器中创建 主持人项目 （申请入境点）。对于作为exe项目的Windows.Forms应用程序。
通常在简单的解决方案（10个项目下）中，只有主机项目应该引用IoC库。
注册组件时有几种可能性：
注册代码：
注册配置文件：
顶级是一种方式（UI，如Rinat所说）。
现在，对于引用，最简单的方法是遍历当前文件夹中的所有程序集，并使用一些约定来获取服务。属性工作正常，每个程序集中的注册表类都可以正常工作，无论适合您。提取所有内容的代码应该在一个单独的程序集中，除非你的IoC框架已经这样做了。
模块的区别和模块定义的“范围”主要存在于编译时。在运行时它是一个大问题;）大多数IOC容器使用它，他们并不真正关心它们的位置。 Web应用程序的IoC容器通常会在最外层创建（非常靠近Web容器本身）。
你可以在任何地方创建它，但我会引入一个额外的层，我们称之为3.5。
您当前的3将是您的IoC驻留数据访问的位置 - 这将成为您的实际DAL的包装。根据您的配置，3将创建模拟存储库或具体存储库。
所以2仍然引用3，但它只是通过IoC框架配置的实际DAL的接口。
或者，您可以推出自己的“el-cheapo”IoC - 将您的Big Ugly Singleton更改为静态网关 - 在单身人士背后提取IoC容器 - 做错了吗？