Windsor WCF设施和打字工厂

时间:2012-07-03 10:54:22

标签: castle-windsor wcffacility typed-factory-facility

我的问题与温莎提供的WCF和键入的工厂设施有关。我是IoC容器概念的新手,尤其是设施,但在评估了我们之前写的一个项目之后开始研究它。该程序是n层的,不是单元可测试的,因为依赖注入并未在任何地方实现。问题在于,由于它是n层的,所以做一个正确的DI最终会使顶层负责创建一个像5层一样被使用的东西的实例;所以我转向IoC。

然而,在阅读了很多SO文章和其他网站后,我现在遇到了一些问题。最初的一个主要问题是将类与WCF服务的物理实现分离,我按如下方式进行:

service = ManagerService.IoC.Resolve<IGridSubmitWorkService>(new { binding = new BasicHttpBinding(), remoteAddress = new EndpointAddress(WorkerAddress) });

result = service.SubmitWorkUnit(out errorString, aWorkUnit);
ManagerService.IoC.Release(service);

但是,我发现有多个提及你应该如何使用IoC.Resolve<>(),而应该使用工厂和WCF工具去除对IoC container的依赖,并且它是一个服务定位器模式有些人认为是反模式。

我的问题是:上面三行代码几乎解决了我的所有问题,但是要遵循正确的模式,我必须创建一个WCF工具,一个类型工厂(它将处理为我提供类的实例)代码被使用)和工厂的新界面,这感觉就像过度工程并为代码 添加不必要的复杂功能,以便取悦模式。

问题1:我在这里缺少一些基本的东西吗?

问题2:正如您从代码中看到的,我正在为Web服务调用非空构造函数。如果我实现WCF工具,这仍然会如此简单吗?

问题3:您能否指点我使用WCF设备的体面教程,因为我发现Windsor wiki上的解释非常简短而且没有用处?

由于

1 个答案:

答案 0 :(得分:1)

Q1。是的,我认为有一些重要的错过。在您的三行示例中,您所做的就是将一个实现依赖项(您的GridSubmitWorkService)替换为另一个(ManagerService.IoC)。为了说明,为什么不用以下内容使其更简单?

service = new GridSubmitWorkService(binding,remoteAddress);
result = service.SubmitWorkUnit();

这再次更简单,但它具有硬连线实现依赖性。关键是构造函数和属性注入允许您编写干净的组件,而不必了解管道是如何完成的。在您的代码和我的代码中,违反了原则 - 组件正在管理自己的管道,并且在大型应用程序中,这变得非常痛苦,非常快。这就是为什么ServiceLocator被许多人认为是反模式的原因。

服务定位器的名称本身就让游戏消失了。它被称为IoC - 控制反转的缩写。但是当你看到这两段代码的结构时,你可以清楚地看到没有任何东西被反转 - 在这两种情况下代码都做了几乎相同的事情,但你的例子只是一点点更抽象,更复杂。

也没有人提供IoC试图迫使你坚持一个模式。如果你没有看到好处或者好处不适合你的应用,那么请不要使用这种模式。

Q2。任何体面的DI容器都基于构造函数注入。使用Windsor WCF工具非常简单,它支持各种托管方法,所以无论如何都能正确处理绑定和地址等事情。

Q3。除了Windsor文档和维基之外,还有很多关于stackoverflow.com上论坛和问题的信息。如果您无法解决问题,我建议提出具体问题。

豫ICP备18024241号-1