为什么WCF客户端依赖于app.config文件？

Question

像很多事情一样，我确信这是有充分理由的，所以请帮助我理解......

默认情况下，为什么在app.config中执行WCF服务存储设置？

尝试使用多个Silverlight类库非常令人沮丧。这些类库应该完全相互独立，这种对app.config的依赖似乎会引起以下令人头疼的问题：

1. 单一责任原则 - 我应该能够添加对类库的引用并继续。如果该类库使用服务引用，那么在我开始编写它之前就会出现这个想法。
2. 泥泞的配置 - 为了让其他库工作，我必须将服务配置复制并粘贴到“主”应用程序配置中。如果端点以任何方式发生变化，我不能只担心该类DLL的新版本 - 我也要担心使用它的任何东西。
3. 复杂的替代方案 - 以编程方式创建端点并不漂亮。周期。

必须有更好的方法。为什么WCF至少不将服务配置分成 ServiceName.config 或者被复制到输出目录的东西。我错过了什么？你怎么处理这个？

Answer 1

因为替代品也不是很好。 “ServiceName.config”的问题是ServiceName也需要是可配置的。

根本问题是在库中开始使用服务引用。并且库组件不能指定App的绑定。所以你的SRP论证不成立。

Answer 2

我同意@Henk - 库程序集不应该有WCF引用。如果由于某种原因它确实需要一个，我会使用依赖注入，并将服务引用传递给库函数 - 这对于最大化测试的好处至关重要。

我也不会购买“以编程方式创建端点并不漂亮”的论点。创建和分配端点只是几行代码，并且是我几乎专门使用我的Silverlight组件的技术（例如，如果 ServiceReferences.ClientConfig 文件中没有指定地址，那么我就会失败回到托管应用程序中的已知服务位置，在这种情况下，这些端点是以编程方式创建的。

基本上，如果您不介意以编程方式创建端点所需的几行代码，那么您可以在任何配置文件中的任何位置存储您的地址详细信息。如果您要采用纯粹的声明性方法，则只需要在app.config中存储地址。