温莎 WCF 设施和类型工厂答案

【问题标题】：Windsor WCF facility and typed factories温莎 WCF 设施和类型工厂
【发布时间】：2012-07-04 06:12:07
【问题描述】：

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

谢谢

【问题讨论】：

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

【解决方案1】：

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

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

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

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

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

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

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

【讨论】：