Question

我的问题与温莎提供的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上的解释非常简短而且没有用处？

由于

Answer 1

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

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

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

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

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

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

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

Windsor WCF设施和打字工厂

1 个答案: