WCF，为什么让它更复杂

本文关键字：复杂 为什么 WCF | 更新日期: 2023-09-27 17:51:10

今天我有一个关于WCF沟通风格的问题。

我有时会拒绝一点，所以用编程的方式使用东西(想要控制自己)，我不喜欢巨大的。有时两个程序部分之间需要通信，有时在同一台机器上，有时在网络上。

所以我尝试以编程方式使用WCF，而不是使用配置文件，svcutil等。

如果我使用以下命令:

a)定义合同

[ServiceContract]
    public interface IMyContract
    {
        [OperationContract]
        bool DoSomething(string something_in);
    }
b)编写一些代码 
public class MySomething: IMyContract
        {
            public bool DoSomething(string something_in)
            {
                if(String.IsNullOrEmpty(something_in)
                      return false;
                return true;
            }
}

，然后以编程方式托管它

Uri baseAddress = new Uri("net.tcp://localhost:48080/MySimpleService");
            using (ServiceHost host = new ServiceHost(typeof(MyContract), baseAddress))
            {
                host.AddServiceEndpoint(typeof(IMyContract), new NetTcpBinding(), "");
                host.Open();
                Console.WriteLine("<Enter> to stop the service.");
                Console.ReadLine();
                host.Close();

，然后从另一个程序中使用它:

var binding = new NetTcpBinding();
            var endpoint = new EndpointAddress("net.tcp://localhost:48080/MySimpleService");
            var channelFactory = new ChannelFactory<IMyContract>(binding, endpoint);
            IMyContract client = null;
            try
            {
                client = channelFactory.CreateChannel();
                bool test = client.DoSomething();
                ((ICommunicationObject)client).Close();
            }
            catch (Exception ex)
            {
                if (client != null)
                {
                    ((ICommunicationObject)client).Abort();
                }
            }

缺点是什么?

这样不是更容易理解吗?

这样的事情会引起其他问题吗?

(我最感兴趣的是这个，因为我认为使用svcutil是非常烦人的，所以一个只是因为类的变化，这可以简单地手动处理，如果wcf服务只用于自己的程序通信)那么我错过了什么呢?

它只是一个坏的风格来做事情手动而不是大的未读XML文件?

WCF，为什么让它更复杂

你的问题可以分为多个部分:

可以硬编码地址吗?

。同样，我们不会硬编码连接字符串，也不会硬编码资源或服务的路径(至少不是绝对路径)。您永远不知道什么时候出于某种原因需要更改它——例如测试新版本的服务。如果你不想使用完整的端点配置，至少使用简单的应用程序设置。

是否可以硬代码绑定和配置?

如果你不希望经常更改它，如果你喜欢每次更改时重新编译和重新部署服务器和客户端，你可以硬编码它。API提供了这个，因为它是有效的用例。

是否可以在客户端之间共享服务契约和数据契约和服务器?

同样，这取决于您对应用程序增长的预期方式以及您对部署复杂性的预期。如果您完全控制客户端和服务器代码，那么共享程序集是有效的用例，但您必须记住，它会在服务器和客户端应用程序之间引入紧密耦合。Svcutil是一种工具，它可以帮助您从您无法控制的SOAP服务(您没有它们的代码或它们不是用。net编写的)生成客户端，或者用于您希望与服务器进行松耦合的客户端。

我自己经常使用配置共享契约程序集= no svcutil.

编辑:

无论如何，编码配置与XML配置相比没有技术上的缺陷(一些高级配置甚至在XML中不可用)。如果一个开发人员了解WCF，他就能同时理解XML和代码。如果开发人员不了解WCF，他可能会对代码更满意，因为XML配置可能会对他隐藏一段时间。

通过编程的方式完成应该可以很好地工作。当您想要更改某些内容时，或者要求最终用户更改某些内容时，主要问题就会出现。如果端点地址或其他配置将改变，则不必重新编译代码将容易得多。

我想说使用配置文件会更好，这样设置就保存在一个单独的地方，并且在需要的时候很容易找到。

我只会选择硬编码配置，如果你有很好的理由想要隐藏它从用户(例如，你不想让他们看到它/打乱它)。

相关文章：