为什么会使用ChannelFactory来实例化WCF代理而不是服务引用？
似乎有两种方法可以实例化此处描述的WCF服务代理。 我的问题是为什么要使用ChannelFactory来实例化WCF代理，这种方法有什么好处？
我遇到了对第二种选择有强烈意见的人，但我无法理解他们的明确论证
如果你正在使用汇编共享（这是让我们面对它，如果你拥有管道的两端非常方便），那么如果接口等两端已经有了完整的版本。运行svcutil工具似乎是多余的（在命令提示符或通过IDE）只是为了获取我们已有的包装器。 当您只想编写接口而不是包装类时，它也能很好地工作 – 并使用一些集中代码来获取给定地址的特定接口的通道。 这实际上是我主要使用WCF的方式。
“客户”方法适用于一次性服务，或者不需要通过任何中央工具。 它还可以进行非常简单的演示。
第一个选项使用web.config / app.config文件中提供的配置设置来实例化代理，但是在某些情况下将这些设置放在该文件中是不可行的，例如，如果您的应用程序需要使用不同的绑定（可能HTTP与命名管道）取决于方案，或者您的应用程序可能甚至没有.config文件。
第二个选项在创建代理时提供了更大的灵活性，以便在实例化时以编程方式指定要用于每个代理的配置。
举一个更具体的例子，假设您希望在与本地计算机通信时使用命名管道进行通信，如果与远程主机通信则使用HTTP：
if (UseNamedPipes()) { EndpointAddress address = new EndpointAddress("net.pipe://localhost/Simple/BankService"); return ChannelFactory.CreateChannel(new NetNamedPipeBinding(), address); } else { EndpointAddress address = new EndpointAddress("http://localhost:8000/Simple/BankService"); return ChannelFactory .CreateChannel(new BasicHttpBinding(), address); }
其中一个具体案例是在开发任何没有app.config文件的办公室加载项或visual studio加载项项目时。
另外，假设您要在某个组织中标准化某些绑定和某些端点安全模式。 您可能希望创建一个开发人员可以轻松用来创建代理的API，在这种情况下，您将使用channelfactory封装所有绑定信息。