0

我的问题与温莎提供的 WCF 和类型化工厂设施有关。我对 IoC 容器概念，尤其是设施非常陌生，但在评估了我们不久前写的一个项目后开始研究它。该程序是 n 层的并且不是非常可单元测试的，因为依赖注入并不是到处都实现的。问题在于，由于它是 n 层的，因此进行适当的 DI 最终会使顶层负责创建一个实例，该实例将被使用 5 层以下；所以我转向国际奥委会。

但是，在阅读了许多 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：由于我发现 Windsor wiki 上的解释非常简短而且没有真正用处，您能否指出一个关于使用 WCF 设施的体面教程？

谢谢

4

1 回答 1

1

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

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

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

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

也没有人提供 IoC 试图强迫你坚持一种模式。如果您没有看到好处，或者您的应用程序根本没有好处，那么请不要使用该模式。

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

Q3。除了 Windsor 文档和 wiki 之外，stackoverflow.com 上还有大量信息，从论坛到问题。如果有您无法解决的问题，我建议提出一个具体问题。

于 2012-07-03T22:12:07.067 回答