WCF编码规范.docVIP

WCF编码规范 一个全面完整的编码规范是成功交付产品的根本。规范有助于推行最佳实践以及避免缺陷，可以让团队成员更容易分享知识与技能。传统的编码规范是一本浩如烟海一般的高文大册，厚达数百页，详尽了每个指南的基本原理。制定这样的规范固然是有胜于无，然而，如此努力却很难被大多数开发者所接受。比较而言，本书介绍的WCF编码规范却只有薄薄的几篇，主要介绍了WCF编码细节、编码内容以及设计目的。我相信，若要充分理解各种编程决策，可能需要阅读大量书籍，积累数年的经验，然而如果要实施编码规范则不必如此。当吸收一名新兵加入你的团队时，你可以交给他这份规范，告诉他：“先看看这个。”若要完全理解以及认识到范围的价值，或许需要时间与经验，然而，如果只是需要在此之前就能够遵循规范的约定，却是一蹴而就的事情。编码规范详细介绍了编码要求、缺陷、指南以及建议。编码规范同时还使用了本书介绍最佳实践以及辅助类。 通用设计指南 所有的服务必须遵循以下原则： 服务是安全的。 服务操作在系统中应该保持状态一致。 服务是线程安全的，且可以被并发客户端访问。 服务是可靠的。 服务是健壮的。 服务应该遵循以下可选原则： 服务是可互操作的。 服务的规模是不变的。 服务是可用的。 服务是及时响应的。 服务是受限的，阻塞客户端的时间不能过长。 WCF基础 应该将服务代码放入到类库中，而不是放到宿主EXE中。 不要为服务类提供参数构造函数，除非托管的服务是明确的单例服务。 在相关的绑定中启用可靠性。 要为契约提供有意义的命名空间。对于公开向外的服务，可以使用公司的URL或者等同的URN，然后加上年份和月份以避免版本冲突；例如： [ServiceContract(Namespace = /2009/06)] interface IMyContract {...} 对于局域网服务，可以使用任何有意义的唯一的名称，如MyApplication；例如： [ServiceContract(Namespace = MyApplication)] interface IMyContract {...} 对于运行在Windows XP以及Windows Server 2003 上的局域网应用程序，最好选用自托管，而不是IIS托管。 在Windows Vista和Windows Server 2008或更近版本中，最好选用WAS （IIS7）托管，而不是自托管。 启用元数据交换。 要为客户端配置文件中的所有终结点命名。 不要使用SvcUtil或者Visual Studio2008生成配置文件。 不要复制代理的代码。如果两个或多个客户端使用相同契约，可以将代理分解到单独的类库中。 总是关闭或释放代理。 服务契约 总是将ServiceContract特性应用到接口上，而不是类上： //避免 [ServiceContract] class MyService { [OperationContract] public void MyMethod() {...} } //正确 [ServiceContract] interface IMyContract { [OperationContract] void MyMethod(); } class MyService : IMyContract { public void MyMethod() {...} } 服务契约要添加前缀I： [ServiceContract] interface IMyContract { [OperationContract] void MyMethod(); } 要避免准属性（Property-Like）操作： //避免 [ServiceContract] interface IMyContract { [OperationContract] string GetName(); [OperationContract] void SetName(string name); } 避免定义只有一个成员的契约。 每个服务契约最好只定义3~5个成员。 每个服务契约的成员不要超过20个。12个是可能的实际限定。 数据契约 避免推断式数据契约（POCO）。总是显式地应用DataContract特性。 只在属性或只读公有成员上使用Datamember特性。 避免为定制类型显式地执行XML序列化。 避免使用消息契约。 当使用DataMemberAttribute特性的Order属性时，应该为同一类层级的所有成员分配相同的值。 数据契约应实现IExtensibleDataObject接口。使用显式接口实现。 避免在ServiceBehavior和CallbackBehavior特性上设置IgnoreExte