【发布时间】：2010-11-03 23:58:13
【问题描述】：
有没有人对此深思熟虑？就个人而言，我认为在配置文件中管理端点很痛苦。做一个比另一个有什么优点/缺点？
【问题讨论】：
标签： wcf configuration endpoints
【发布时间】：2010-11-03 23:58:13
【问题描述】：
查看.NET StockTrader app。它使用存储库来存储配置数据，并有一个单独的应用程序来管理配置。设置和结构非常先进，对于像我这样的人来说，到目前为止只有 WCF 配置的基础知识，但我会说它值得一看。
【讨论】：
我自己也喜欢配置方法，除了配置文件会变得很大。
我在 WCF 配置中注意到的一件事是，您可以从代码中做很多事情，而在 XML 配置中 不能添加您自己的自定义扩展。换句话说，在代码中进行配置将提供更大的灵活性，当然您也可以编写自己的扩展并使用配置中的扩展。
但是，请注意，我认为 Visual Studio 中有一个“错误”，如果您开始制作自己的扩展并将它们包含在 XML 中，那么 VS 将不再喜欢您的配置文件并将标记它们作为错误，然后如果您尝试通过向导添加新服务，它将无法将端点添加到配置中。
这是对我自己的回答的一种跟进：
经过几个月的 xml 配置后，我将更改所有内容以在代码中构建端点和绑定。我发现了一个非常好的案例，可以在代码中使用它；
当您想要一个包含 WCF 客户端的可部署/共享 .dll 时。
因此，例如，如果您有一个 CommonClients.dll，其中包含所有 WCF 接口和合同以与某个远程服务器通信，那么您也不想说“这里有 100 行 xml，您也必须删除到您的 app.config 中，让每个客户端都能正常工作”。在这种情况下，将其全部构建在代码中效果会更好。
.NET 3.5 还有一个“特性”，如果你有一些 wcf 扩展，你必须指定完全限定的程序集名称。这意味着如果包含扩展的程序集更改版本号，您也必须更改配置文件中的程序集名称。它应该在 .NET 4 中修复为使用短程序集名称而不需要全名。
【讨论】：
我更喜欢并推荐配置文件的方式。它通过允许对您的服务器进行更改而无需重新编译应用程序，从而提供了很大的灵活性。 如果你需要安全，你可以加密配置文件。
使用普通配置文件的最大担忧可能是最终用户可能会意外（或故意）修改它，从而导致您的应用崩溃。为了克服这个问题，您可以在代码中进行一些测试以检查配置文件中的配置是否正常，如果不是，则以编程方式将其初始化为一些默认值。我在对 this 问题的另一个回答中介绍了如何做到这一点。
【讨论】：
我通常会进行编程配置，因为我不想将我的应用程序内部结构暴露给用户。我唯一可以配置的是服务地址，但即便如此，我也保留在 userSettings 部分，而不是 system.ServiceModel。
【讨论】：
使用 app.config 时，您的应用程序无需重新编译以适应更改。此外，它可以在多种情况下使用完全相同的代码重复使用。最后，硬编码你的端点（或任何可能发生变化的东西）是糟糕的编码实践。不要害怕配置文件，它是声明式编程。你说，“我想使用这个端点。”它会为你工作。
【讨论】：
这只是您需要多少灵活性的问题。 通常我更喜欢配置文件的方式。
【讨论】：
顺便说一句，配置文件中的端点在更改时不需要重新编译。这也意味着在将应用程序从 Development 移动到 UAT 再到 Production 时，您只需更新配置文件。
如果您只是在家里编写一些代码供自己使用，那么并没有真正的区别。但是在业务环境中，在配置文件中定义 enpoint 可以省去各种麻烦。
【讨论】：
只支持我的配置文件。
在配置文件中管理端点意味着如果（或者我应该说何时）端点发生变化，您不必更新应用程序。
您还可以让应用程序的多个实例使用不同的端点运行。
【讨论】：