Question

我正在学习如何使用WCF服务，我开始遵循this MSDN article的6步教程。在第4部分中讨论了使用svcutil.exe生成客户端代码~~，第5部分显示了一个配置WCF客户端~~的令人讨厌的XML文件。使用svcutil.exe ~~和这个XML~~ 相对于我为WCF演示采用的非常简单的解决方案而言似乎太沉重了：

class Program
{
    static void Main(string[] args)
    {
        WSHttpBinding bhb = new WSHttpBinding();
        EndpointAddress epa = new EndpointAddress("http://localhost:8000/index/ServiceReference1");
        ChannelFactory<ServiceReference1.IDemoChannel> cf = new ChannelFactory<ServiceReference1.IDemoChannel>(bhb, epa);

        cf.Open(); 
        ServiceReference1.IDemoChannel channel = cf.CreateChannel();
        channel.Open();

        String s = channel.getHelloWorld(5);
        channel.Close();
        cf.Close();
        Console.WriteLine("Result: {0}", s);
        Console.WriteLine("I'm the client! Press Enter to exit...");
        Console.ReadLine();
    }
}

~~看过这两种截然不同的配置客户端的方法，我想知道使用生成的代码和XML文件有什么好处，什么时候比编程方法更好？~~

更新：我在本教程的第5部分中重新阅读了XML文件，似乎XML文件是重复的并且查看了预期的XML，我收回了我的问题的XML方面。我认为我真正要问的是“为什么我想在编写客户端代码时使用svcutil.exe生成我的代码并不是那么糟糕”？

Answer 1

在我看来：始终使用XML ，因为您可以在部署程序后更改它，只需重新启动服务即可。

如果你使用你的演示代码，你需要重建，重新编译，重新部署，等，并且比使用 XML 更强 强>

Answer 2

除了可以轻松更改xml配置之外，svcutil（或向项目添加服务引用）的另一个巨大好处是wcf方法所需的自动生成类型，这些类型可供您使用而无需引用宣布集会。在hello world示例中，方法返回一个字符串，这无关紧要，但是大型wcf实现可能有很多请求/响应类型。

Answer 3

“为什么我要在编写时使用svcutil.exe生成代码客户端代码看起来不是那么糟糕“？

当您编写一个简单的测试程序时，您在代码中所做的工作效果很好。

当您开发需要团队和维护的较大应用程序时，xml配置是更好的选择。想象一下，该服务由完全不同的团队编写和维护，他们不会让您阅读他们的代码。客户端配置必须与服务上的配置完全匹配。当服务团队更改uri，或端口，或使用证书（https）时，您将如何找到客户端开发人员？调用将失败（可能是一个非常无法提供的错误消息）。你是如何解决的？只需再次运行svcutil并重新生成配置。无需召集会议，阅读（希望）更新的文档等。

回到您的示例测试代码示例：您的服务到达部署在localhost以外的地方的那一刻，您必须重新编译客户端，除了更新网址之外没有其他原因...那就是您将要开始了解在配置中定义连接信息的价值。在那之前，不要担心。

在Windows Communication Framework中，何时更好地以XML而不是以编程方式定义客户端配置？

3 个答案: