我是IoC的新手,因此一直关注Jeffery Palermo在http://jeffreypalermo.com/blog/the-onion-architecture-part-1/的帖子中提供的示例以及他在这里托管的书https://github.com/jeffreypalermo/mvc2inaction/tree/master/manuscript/Chapter23
最值得注意的是,我没有使用预先推出的IoC容器,主要是因为我想了解所有移动部件 .
但是,我正在创建一个Windows服务而不是ASP.NET MVC webapp,所以我很少陷入启动部分 . 具体来说,在web.config中,他将基础结构项目中的IHttpModule实现注册为启动模块,然后使用构建后事件将必要的dll复制到网站目录中,以便在Web项目本身中直接依赖 .
我不认为我在真正的Windows服务中有这种类型的奢侈品,所以我如何实现类似的东西,我应该有一个小的启动项目,它依赖于基础设施和核心,还是有另一种方法可以解决Windows服务的编译时限制?
提前致谢 .
2 回答
根据这个问题的标签(c#)我'm assuming that you'll通过从ServiceBase派生来实现Windows服务 . 如果是这样,OnStart方法将是您的 Composition Root - 这是您组成应用程序的地方's object graph. After you' ve组成对象图,组合结束,组合对象图接管 .
在OnStop中,您可以再次停用对象图 .
没有什么能阻止您在单独的程序集中实现已解析对象图的各种组件 . 这就是我要做的 .
我想您错过了IoC框架的作用 .
回答你的问题
是的确如此,但在另一个层面上 . IoC是关于类之间的依赖关系 . 您不必在类中使用
new Something()
,而是提供需要所有相关接口的构造函数 . 这样,类无法控制将哪个实现传递给它 . 这是控制的倒置 . IoC容器只是帮助以一种很好的方式管理依赖项 .假设你有一个带有类似实现的
ICustomerNotificationService
接口因此,如果您的应用程序请求
ICustomerNotificationServcie
的实例,容器将确定要采取的具体实现,并尝试满足所请求的类具有的所有依赖项 .优点是您可以轻松配置引导逻辑中的所有依赖项,并且能够非常轻松地更改应用程序的行为 .
例如,在测试时,您使用
IMailerService
实现启动应用程序,该实现将邮件写入文件,并在 生产环境 模式下连接实际邮件服务 . 如果你在你的构造函数中新建一个MailerService
而不是将它作为参数,那么这是不可能的 .一个好的IoC容器可以处理更多,就像你想要注册的类型的生命周期管理,单例,扫描程序集等等 . 例如,我们将整个插件系统基于Structure Map .
你可能想看一下this blog article及其second part .