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为您管理它们.考虑超时的依赖关系,重新创建新的实例>可能是长时间运行的任务,创建单独的内核实例,并确保您之后处理它们 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |