使用WCF简化IOC容器

Question

在article article之后的article中，任何有关在IIS中使用IOC容器（Unity，Windsor等）的讨论都涉及创建自定义ServiceHostFactory和自定义ServiceHost

我能看到的唯一原因是，可以将具有IInstanceProvider相关有效负载的自定义服务行为应用于所有服务。所以我试图理解为什么整个事件没有通过anonymous service configuration来简化。此类配置允许将自定义行为应用于所有服务，而无需使用自定义ServiceHostFactory和自定义服务主机。

也就是说，如果自定义的IInstanceProvider与每个WCF实例或上下文实例一起回收，那么我可以想象自定义服务主机的唯一原因是必要的。当然，我希望每次启动IIS ServiceHost时都只建立一次IOC容器绑定，而不是重复或不定期。

如果我的自定义IInstanceProvider确实被偶尔回收，那么我可以将我的IOC容器放入自定义服务主机 - 以确保它会尽可能长时间地停留。

但是，如果我的自定义IInstanceProvider将持续与内置服务主机一样长，那么为什么不跳过自定义服务主机工厂和自定义服务主机？

事实上，如果我把我的IOC容器放入我的自定义IInstanceProvider的静态成员中，那么，如果IInstanceProvider被不规则地回收也没关系。它是全方位的：为什么我需要或想要一个自定义ServiceHostFactory和自定义ServiceHost来使用带有WCF的IOC容器？

Answer 1

好。这是因为大多数IoC / WCF集成（如mine）不仅仅是创建您的服务（具有它的依赖性）。

自定义生命周期/处置

请求结束后，一切都应该得到妥善清理。您的服务和IoC课程使用不同的生命周期。

只有在InstanceProvider的帮助下才能检测到请求的结尾。

IContractBehavior / IServiceBehavior

您可以在容器中注册行为，并automatically将其添加到您的WCF服务中。

Answer 2

就个人而言，我喜欢使用您不需要任何ServiceHostFactory，ServiceHost，ServiceBehavior和InstanceProvider组合的设计不必在.svc文件中注册工厂。我喜欢我的WCF服务，只是在消息传递架构之上的一个非常薄的层，这使您免于使用此WCF集成的东西。您可以阅读有关此类设计的更多信息here。

Answer 3

有趣的问题！我想这样做的唯一原因是你不希望用你永远不会改变的项目（即你的WCF服务使用的IoC容器）弄乱你的app.config。我尝试将app.config的使用限制在最终用户/开发人员可能想要更改的内容而不重新编译（在大多数情况下，并不多）。这使得它更具可读性，并且通常更容易以编程方式指定配置，因为与配置文件相比，在程序代码中更好地支持intellisense和编译时检查。

但是，此参数可能不适用于您链接的第一篇文章，因为它们实际上是通过app.config设置其IoC容器。所以在这种情况下它可能是双重标准。我从来没有真正理解为什么人们想要通过外部配置文件设置所有依赖项。在大多数情况下，在app.config中存储静态配置对我来说似乎有些过分。