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

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

  1. Winforms UI
  2. 商业逻辑
  3. SQL Server数据访问(实现IRepository)
  4. 通用接口(IRepository等的定义)

我的业务逻辑(2)使用构造函数dependency injection通过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库。

PS: 使用Autofac IoC构建.NET应用程序

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

  1. 注册代码:


    • 问题:你必须参考一切(你在这里)
    • 间接
      问题:找出必须注册的内容
      解:
      1. 使用属性
      2. 使用标记接口作为IService
      3. 使用约定(参见StructureMap)
  2. 注册配置文件:

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

顶级是一种方式(UI,如Rinat所说)。

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

模块的区别和模块定义的“范围”主要存在于编译时。 在运行时它是一个大问题;)大多数IOC容器使用它,他们并不真正关心它们的位置。 Web应用程序的IoC容器通常会在最外层创建(非常靠近Web容器本身)。

你可以在任何地方创建它,但我会引入一个额外的层,我们称之为3.5。

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

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

或者,您可以推出自己的“el-cheapo”IoC – 将您的Big Ugly Singleton更改为静态网关 – 在Singleton背后提取IoC容器 – 做错了吗?