序言
对于一次成功的产品交付来说，完整编码规范至关重要。这个规范可以帮助强化一些通用的最佳实践准则，并避免犯错，方便整个团队理解这些知识。通常，编码规范都是相当的繁琐，动辄上百页，内容详细叙述每个编码规则的基本原理。虽然这比没有规范要好的多，但是通常开发人员难以理解和掌握。相反，《
WCF
编码规范》只有
10
多页，并且详细介绍“是什么”和“为什么”。我相信要完全理解每个编码规则的精髓并恰当地应用这些规则，需要阅读大量的书籍和多年的工作经验。当有新人进入团队时，你可以快速地告诉他或她应该“先看看这个规范”。因为，完全理解这些规范需要时间和今年感言，在此之前，我们就应该遵守它。这里涵盖了一些常用的规则、缺陷、指南和建议。这里会使用在《
WCF Master Class
》和《
Programming WCF Services
》（精通
WCF
课程和
WCF
服务编程）里介绍的最佳实践和
Helper Class
。
Juval Lowy
General Design Guidelines
通用设计规范
1.
All services must adhere to these principles:
所有的服务必须遵守这些原则：
a)
Services are secure.
服务是安全的。
b)
Service operations leave the system in a consistent state.
服务操作保证系统在一直的状态。
c)
Services are thread-safe and can be accessed by concurrent clients.
服务是线程安全的并且可以被并发的客户端访问。
d)
Services are reliable.
服务是可靠的。
e)
Services are robust.
服务是健壮的。
2.
Services can optionally adhere to these principles:
这些原则不是必须的。
Services are interoperable.
服务是可互操作的
Services are scale-invariant.
服务是可以伸缩的
Services are available.
服务是可用的
Services are responsive.
服务是可以相应的
Services are disciplined and do not block their clients for long.
服务是遵守规则的，不能长时间阻塞客户端进程。
Essentials
设计要点
Place service code in a class library,not in any hosting EXE.
服务类应该定义在类库而不是
exe
宿主里。
2. Do not provide parameterized constructors to a service class,unless it is a singleton
that is hosted explicitly.
3.
Enable reliability in the relevant bindings.
在相关的绑定里启用可靠性。
4. Provide a meaningful namespace for contracts. For outward-facing services,use your
company’s URL or equivalent URN with a year and month to support versioning.
For example:
例如：
[ServiceContract(Namespace = "http://www.idesign.net/2009/06")]
interface IMyContract
{...}
For intranet services,use any meaningful unique name,such as
MyApplication
.
对于企业内部服务，使用唯一的有意义的名字，比如
MyApplication
。
For example:
例如
:
[ServiceContract(Namespace = "MyApplication")]
interface IMyContract
{...}
5. With intranet applications on prefer self-hosting to IIS hosting when the WAS is
unavailable.
对于企业内部应用系统，当
WAS
不可用的时候，推荐自托管
self-hosting
而不是
IIS
。
6. Do not mix and match named bindings with default bindings. Either have all your
bindings be explicitly referenced,or use only default bindings.
不要混用指定绑定和默认绑定。要么全部明确指定绑定，要么只使用默认绑定。
7. Do not mix and match named behaviors with default behaviors. Either have all your
behaviors be explicitly referenced,or use only default behaviors.
不要混用指定行为和默认行为，要么全部明确执行行为，要么使用默认行为。
8. Always name all endpoints in the client config file.
在客户端的配置文件里，定义终结点的名字
name.
9. Do not use SvcUtil or Visual Studio 2010 to generate a config file.
不要使用
SvcUtil
工具或者
Visual Studio 2010
去生成配置文件。（这里工具会使用很多默认的设置，这些会带来潜在的问题，在产品部署以后，比如TimeOut和MessageMaxSize等，最好自己能手动更改这些配置）
10. When using a tool such as Visual Studio 2010 to generate the proxy,do clean up the
proxy.
11. Do not duplicate proxy code. If two or more clients use the same contract,factor the
proxy to a separate class library.
不要复制代理代码。如果两个或多个客户端使用了相同的契约，把代理分解到独立的类库里。（这里不建议复制Proxy代码的方式。如果你有多个客户端，比如A是一个Console程序，B是一个WindowsService程序，C是一个WinForm程序,都调用了相同的WCF服务，可以把这个WCF客户端放在一个类库里DLL，其它项目都引用即可）
12. Always close or dispose of the proxy.
13. When using discovery,prefer dynamic addresses.
当使用服务发现机制的时候，推荐动态地址。（动态定位服务地址是
WCF
服务发现的优势）
14. When using discovery,do support the Metadata exchange endpoint over TCP.
15. When using discovery,avoid cardinality of “some”.
当使用服务发现机制的时候，避免使用不确定的基数
(WCF4.0
里，查找终结点的个数，这里明确数目，
FindCriteria.MaxResults = 1
)
原文链接：https://www.f2er.com/javaschema/287589.html