c# – 长时间运行的Windows服务中的依赖注入 – 组合根是正确的想法？

我正在编写一个 Windows服务(如果按计划进行的话)会一次运行几个月.在服务的整个生命周期中,它将维护多个WCF服务(用于与其他本地应用程序通信的命名管道),它将运行一个嵌入式数据存储(RavendB或多或少与此问题无关),它将使用一些第三方软件来维护SIP服务(VoIP功能).我面临的一些挑战意味着必须对事件做出反应,并创建一些新的业务对象来处理这些事件代表什么.

现在,我已经阅读了Mark Seemann的书(至少是这个讨论的相关部分),我明白为什么一个服务定位器是坏的,为什么在组合根(在我的情况下的服务起点)处理这个是好的 – 一般情况.

但是,我不明白的是,这可以适用于每一种情况.我可以看到,在您可以在应用程序开始时编写整个根源的情况下,或者像框架中的每个请求使用IoC引擎的类似MVC的情况下,它将是完美的.然而,对于长期运行的服务,我想象在最好的情况下效率会很低,在某些情况下,不可能在前面创建所有的对象.我无法想象能够编写一个非常简单的服务,它可以获得所有可能需要的对象,而且随着生活的发展,也不需要创建新的对象.

现在,这不足以引诱我到黑暗的一面,并牺牲隐藏的依赖,像一个服务定位器会让我做的.但在这里做什么是正确的事情？如果我有一个CallHandlerService,需要创建响应每个来电(因为它使用昂贵的非托管资源,例如),我该如何去做？

组成根只是一点点的服务定位器？

最后一部分不严重,但我仍然希望知道如何正确地解决这个问题.

解决方法

有可能将问题分解为两个：

>如何管理范围

>避免前面创建所有可能的依赖项
>仅创建所需的依赖关系

>如何管理生命周期

保持对已创建的依赖关系的引用
>如果有可能,重用依赖项
>尽快清理它们

如何管理范围

您可以定义几个专业抽象工厂的接口或实现,每个工厂都将仅限于管理其自己的特殊类型的依赖关系.例如：一个用于数据库相关的依赖关系,另一个与SIP相关.那么你可以自己注入工厂,而不是依赖关系,并从中检索依赖关系.

听起来不像服务定位器吗？是的,但它不是服务定位器.您可以在Mark Seemann blog: Abstract Factory or Service Locator?阅读更多.

如果抽象工厂可以,请查看Ninject.Extensions.Factory根据您的IKernel配置自动创建它们

如何管理生命周期

如果你要运行你的服务24-7,这是比较复杂和重要的部分.在这里我可以给你几个实用的建议：

>对于这种服务,外部依赖方(即数据库,服务)的失败是常规的,而不是例外>不要将自己的依赖关系保留在旨在执行性能或重用的代码中>不要使用复杂的生命周期(例如Ninject的命名范围)>尽快发布依赖关系.配置Ninject为您管理它们.考虑超时的依赖关系,重新创建新的实例>可能是长时间运行的任务,创建单独的内核实例,并确保您之后处理它们