引言
因为最近事情比较多对wcf的学习也被耽搁了一阵，今天总算是有一点时间，就把前一
段时间学习的内容在这总结一下，当然更重要一个的目的是和大家交流一下，这样才能
学习的更好。
一、WCF的优势
下面给大家展示一张我在学习过程见到的图片
二、WCF中的Endpoint（终结点）？
首先我们来看看终结点中包括那几个比较重要的部分，也就是我们常说
的“A”“B”“C”,它们分别代表什么?以及它们的作用是什么？
Address：一个要和服务端通讯的客户端要做的第一件事情，就是搞清数据要发给谁？目的地在哪？而Address 正是通过一个Uri 来唯一标示一个WCF 的终节EndPoint）的，它标示了消息发送的目的地。在WCF 数据通讯中，它解决了服务在哪里的问题，通过这个地址我们就可以找到我们要调用的WCF服务。A解决了：Where to locate the WCF Service？
Binding：英文理解为"捆绑，绑定"， Binding实现在Client和Service通信的所有底层细节。如：我们在客户端与服务端传输的时候采用的是什么样的编码，XML？Text？二进制？...采用哪种传输协议进行传输，TCP？Http？以及采用什么样的机制解决安全问题，SSL？加密？...B解决了：How to communicate with service？
Contract：这个东西就是我们常说的契约，它的主要作用是暴漏某个wcf service所
提供的所有的有效方法，它实际上是把每个方法转化成为相对应的消息。 C解决了：What functionalities do the Service provide？
三、应用程序间的通信
首先让大家看一张比较官方的wcf架构图：
上面的图实在是让我们着急啊，这是个什么东西啊？这么复杂，这就是我看到架构图的
第一反应，下面我给大家一种比较简单的解释：
这样图片就比较简单了，简单来说，如果我们客户端和服务端想通信，那么我们的endpointA和endpointB必须完全符合，同样endpointE和endpointtD也是一样的，这因为应用程序之间是靠endpoint来通信的，所以说我们在客户端也必须定义终结点，只有客户端和服务端的终结点完全符合是才能进行通信。
四、WCF配置文件解读
首先来看一下我们在上一篇博客建立的wcf应用程序中的配置文件。
客户端
<?xml version="1.0" encoding="utf-8"?> <!-- 有关如何配置 ASP.NET 应用程序的详细信息，请访问 http://go.microsoft.com/fwlink/?LinkId=169433 --> <configuration> <system.web> <compilation debug="true" targetFramework="4.5" /> <httpRuntime targetFramework="4.5" /> </system.web> <system.serviceModel> <bindings> <basicHttpBinding> <binding name="BasicHttpBinding_IUser" /> </basicHttpBinding> </bindings> <client> <endpoint address="http://localhost:60193/User.svc" binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IUser" contract="ServiceReference.IUser" name="BasicHttpBinding_IUser" /> </client> </system.serviceModel> </configuration>
服务端
<?xml version="1.0" encoding="utf-8"?> <configuration> <appSettings> <add key="aspnet:UseTaskFriendlySynchronizationContext" value="true" /> </appSettings> <system.web> <compilation debug="true" targetFramework="4.5" /> <httpRuntime targetFramework="4.5"/> </system.web> <system.serviceModel> <behaviors> <serviceBehaviors> <behavior> <!-- 为避免泄漏元数据信息，请在部署前将以下值设置为 false --> <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true"/> <!-- 要接收故障异常详细信息以进行调试，请将以下值设置为 true。在部署前设置为 false 以避免泄漏异常信息 --> <serviceDebug includeExceptionDetailInFaults="false"/> </behavior> </serviceBehaviors> </behaviors> <protocolMapping> <add binding="basicHttpsBinding" scheme="https" /> </protocolMapping> <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" /> </system.serviceModel> <system.webServer> <modules runAllManagedModulesForAllRequests="true"/> <!-- 若要在调试过程中浏览 Web 应用程序根目录，请将下面的值设置为 True。 在部署之前将该值设置为 False 可避免泄露 Web 应用程序文件夹信息。 --> <directoryBrowse enabled="true"/> </system.webServer> </configuration>
有很多读者也许会感到奇怪，如果这个程序能正常运行的话，那么我们在前面讲的通信过程岂不是有错？因为我们只是在客户端中发现了endpoint，但是在服务端并没有发现，这是因为vs在生成配置文件的时候，将服务端的endpoint给隐藏了，当我们手动的给服务端添加上配置文件以后，程序会正常执行。
那么为什么没有终结点也会执行呢？答案是我们把WCF寄宿在IIS上，而IIS默认监听的就 是Http协议[B确定了]并且地址也是相对于IIS上的文件地址[A确定了]，合同更不用说了，找到User.svc什么都有了[C确定了]，所以在服务端就没有必要显示的写出system.serviceModel，不信你试试，把服务端的配置文件中system.serviceModel节删除，程序一样可以运行！服务器端的endpoint确定了，客户端的endpoint自然要和服务端去对应，所以IDE在生成客户端的配置文件里endpoint写的很详细的，而服务端却没有endpoint。
配种文件详解
小结
在项目中初次遇到这个东西的时候非常的痛苦，因为一旦有了错误根本不知道在拿下手来调试，当请教别人的时候发现错误原来这么简单，后来想了想是因为我们根本一点都不了解wcf的运行机制以及通信原理，所以在用了一段时间的wcf后决定学习它的原理，这样我们才能运用的更加灵活，也就是说当我们知道了“是什么”以后，还要知道“为什么”，这样的学习过程会让我们大大的提高学习效率，如果有什么理解不对的地方，还请各位读者留言指出！!
