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