市场要求WCF进一步完善其应用性

在.NET 3.0的4项技术（WF、WCF、WPF、WCS）中，WCF是最被国外同行所看好的技术，但应用中WCF却显得门槛有些太高，为了迎合开发市场的需要WCF在很多方面亟待进一步改善。

虽然开发社区对于.NET 2.0 加了4个“壳”就称之为.NET 3.0已经颇有微词很久，但更多的抱怨是在.NET 3.0走出神话、走入项目之后，其中WCF作为相对位置比较底层的新一代分布式组件技术成为抱怨的焦点。与COM+、.NET Remoting、XML Web Service推出时的情况相比，微软的商业宣传似乎分量更足，但实际提供的参考手册发示例相比明显“缺斤短两”。虽然在各种活动中，WCF充分体现出很多优异表现（跨平台调用、隔离具体组件技术、充分利用各种WS-*协议、大幅降低编码量、几乎完全基于配置等），但相信您也注意到，与其他介绍不同，WCF的介绍都会提前把很长的配置文件写好，介绍的时候讲师总是说“时间关系，下面我们导入一个之前配置好的文件”。

从项目实施人员的角度看，WCF的主要问题其时不在于其API功能的丰富性，关键因素是使用它太麻烦：

• 与WF、WPF相比，WCF在Visual Studio.NET里的插件太过简单，绝大部分时间只能依靠配置文件的XSD给开发人员一些提示，在增加配置节、配置元素的时候可以有一些简单的IntelliSense；
• 虽然宣传文档里一直在说WCF的开发很多时候就是ABC（Address、Binding和Contract）的开发，但WCF似乎“大包大揽”的内容太多，以至于Windows Vista SDK中提供的文档远远不能满足很多开发工作，尤其在国内WCF都快成为“阳春白雪”的情况下，很少能找到适合自己项目的精简但比较完整的示例；
• 之前ASP.NET、.NET Security和.NET Remoting的配置文件已经令很多开发人员和部署人员头疼不已，而WCF的配置文件Schema复杂程度很大程度上超越了他们三者的总和，加之各种WS-*标准升级过快，虽然WCF的ABC可以抽象分布式调用的逻辑部分，相对做到Write Once，但部署到一个新环境中WCF的配置文件的调整确实是一个非常痛苦的经历，因为WCF是一个“外壳”，很多时候CLR提示的错误信息对定位配置错误没有多少帮助，项目规模稍大的时候，在不同环境调整WCF文件很可能成为Crazy Anywhere的经历；
• 而且对于已经使用WCF的同行而言，Visual Studio 2008也许意味着一个“新”体验的开始，因为从文件系统、队列到对象实体模型都作了较大的调整（尽管被命名为.NET 3.5），WCF功能上增加了一揽子新特性，项目中的WCF作为分布式组件是否需要一同升级要好好斟酌一下。不仅如此，从发布的Orcas看，WCF的配置文件愈发复杂了，但相应的工具并没有跟上；

即便有来自J2EE社区的压力，WCF在求新、求统一的情况下，为了照顾到开发市场的需要，必须要让自己做到“易用”。照顾好开发人员，很大程度上也等于照顾好自己的利润。