不了解在系统架构中创建IoC容器的位置
假设我有以下4个.net程序集:
- Winforms UI
- 商业逻辑
- SQL Server数据访问(实现IRepository)
- 通用接口(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应用程序
注册组件时有几种可能性:
-
注册代码:
- 直
问题:你必须参考一切(你在这里) - 间接
问题:找出必须注册的内容
解:- 使用属性
- 使用标记接口作为IService
- 使用约定(参见StructureMap)
- 直
-
注册配置文件:
- 让容器做一切
- 自己阅读文件
顶级是一种方式(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容器 – 做错了吗?