以编程方式配置端点与web / app.config

Question

有没有考虑过这个？就个人而言，我认为在配置文件中管理端点是一件痛苦的事。一个人在另一个人之间是否有任何利弊？

Answer 1

只支持我的配置文件。

管理配置文件中的端点意味着如果（或者我应该说什么时候）端点发生变化，您不必更新应用程序。

您还可以使用不同的端点运行多个应用程序实例。

Answer 2

我倾向于自己喜欢配置方法，除了配置文件可以变得非常大。

我注意到WCF配置的一件事是，你可以做的很多东西都是你在不能在XML配置中做的代码添加自己的自定义扩展程序换句话说，在代码中进行配置将提供更大的灵活性，当然您也可以编写自己的扩展并使用配置中的扩展。

但是，请注意我认为在Visual Studio中我会考虑“错误”，如果您开始制作自己的扩展并将其包含在XML中，那么VS将不再喜欢您的配置文件并将标记它们作为错误，然后如果您尝试通过向导添加新服务，则无法将端点添加到配置中。

---

这是我自己答案的后续内容：

经过几个月的xml配置，我正在改变所有内容以在代码中构建端点和绑定。我在代码中找到了一个非常好的案例;

当您想要一个包含WCF客户端的可部署/可共享.dll时。

因此，例如，如果您有一个包含所有WCF接口和合同的CommonClients.dll与某个远程服务器通信，那么您不想也说“这里有100行xml，您还必须删除进入你的app.config为每个客户端使其工作“。在这种情况下，将所有内容构建在代码中的效果要好得多。

还有.NET 3.5的“功能”，如果你有一些wcf扩展，你必须指定完全限定的程序集名称。这意味着如果包含扩展的程序集更改版本号nnumber，则还必须更改配置文件中的程序集名称。据推测，它在.NET 4中已修复为使用短的程序集名称而不需要全名。

Answer 3

另外，配置文件中的端点在更改时不需要重新编译。这也意味着您只需在将应用程序从Development转移到UAT到Production时更新配置文件。

如果您只是在家编写适合您自己的东西，那么就没有什么区别了。但是，在业务环境中，在配置文件中定义的enpoint可以保存各种令人头疼的问题。

Answer 4

使用app.config时，不需要重新编译应用程序以适应更改。此外，它可以在多种情况下使用完全相同的代码重用。最后，对您的端点（或任何可能发生变化）进行硬编码是一种糟糕的编码习惯。不要害怕配置文件，它是声明性编程。你说，“我想使用这个端点。”它为你工作。

Answer 5

我一般都会进行编程配置，因为我不想将我的应用程序内部结构暴露给用户。我唯一可以配置的是服务地址，但即便如此，我仍保留在userSettings部分，而不是system.ServiceModel。

Answer 6

我更喜欢并推荐配置文件方法。它允许在不需要重新编译应用程序的情况下对服务器进行更改，从而提供了很大的灵活性。 如果您需要安全性，可以加密配置文件。

普通配置文件最大的担心可能是最终用户意外（或故意）修改了导致应用程序崩溃的问题。为了解决这个问题，您可以在代码中进行一些测试以检查配置文件中的配置是否正常，如果没有，则以编程方式将其初始化为某些默认值。我在 this 问题的另一个答案中介绍了如何做到这一点。

Answer 7

这只是一个需要多少灵活性的问题。 通常我更喜欢配置文件方法。

Answer 8

查看.NET StockTrader app。它使用存储库来存储配置数据，并有一个单独的应用程序来管理配置。设置和结构非常先进，对于像我这样只有WCF配置基础知识的人来说，有一点让人头疼，但我想说它值得一看。