一切都可以在 WCF 中以编程方式完成吗？还是某些功能的配置文件？
我非常喜欢使用代码、利用 IntelliSense 并开放 C# 语言的所有功能来使用 WCF 但我想确保我不会朝着最终限制我可以访问的 WCF 功能集的方向前进。我对 WCF 的经验非常有限，以至于我不明白使用配置文件的好处，特别是如果您可以在代码中完成所有操作（？）。
注意：我使用的是.NET 3.5。
您能否以编程方式使用 WCF 执行“所有操作”，或者完整的 WCF 功能集是否需要配置文件？
I have a strong preference for working in code, leverage IntelliSense and opening up all of the power of the C# language to work with WCF but I want to make sure that I'm not moving in a direction that ultimately will limit the WCF feature set I can access. My experience is so limited with WCF that I don't understand the benefits of using the configuration files, especially if you can do everything in code (?).
Note: I'm using .NET 3.5.
Can you do 'everything' with WCF programmatically or are configuration files required for the full WCF feature set?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您可以在代码和配置中完成大约 99.8% 的操作。
有些事情只能在代码中完成 - 例如在需要这两个身份验证的呼叫中设置用户名和密码。
似乎有一些事情只能在配置中完成 - 请参阅其他 最近的 SO 问题 为例。
但我认为，如果您更喜欢代码，那么对于绝大多数情况应该没问题。
马克
You can do about 99.8% of things in code as well as config.
Some things can be done only in code - like setting user name and password on a call that requires those two for authentication.
And there appear to be a few things that can be done in config only - see this other recent SO question for one example.
But I think, if you prefer code, you should be fine for the vast majority of cases.
Marc
一个杂乱的评论......
Marc_s 的回答和问题的观点很好（我的两个+1）。
我毫不怀疑以下内容对你们任何一个来说都不会是新闻，但我想指出这一点，以防有人遇到这种情况并且不知道纯粹编程方法的缺点。
从基于配置文件的设置转向编程配置意味着
我承认，所提到的两种“损失”都是值得商榷的——它们会助长坏习惯，并阻止您以尽可能快的方式为客户提供最可靠的解决方案。
更新：我已经实现了一种机制，我使用
ChannelFactory但从 app.config 中获取自定义配置（如果存在），或者提供默认配置（如果不存在）（我的场景是我是其他人流程中的访客，因此不能假设配置文件很容易更新/已经更新，但又不想失去部署后调整设置的选项）An overgrown comment...
Marc_s' answer and the question's perspective is good (two +1s from me).
I have no doubt that the following will not be news to either of you, but wanted to point it out in case someone encounters this and isn't aware of the cons of a purely programmatic approach.
Moving to programmatic configuration from config-file based setup means
I admit that both of the cited 'losses' are debatable - they can encourage bad habits and prevent you from reaching the most solid solution for your customers in the quickest manner possible.
UPDATE: I've implemented a mechanism where I use
ChannelFactory<T>but pick up a customised config from the app.config if it's present, or provide a default if it isn't (my scenario is that I'm a guest in someone else's process and hence can't assume a config fuile is easy to update / has been updated, yet dont want to lose the option of tweaking settings after deployment)