WCF
服务编程设计规范
(2):
序言、通用设计规范和要点。主要翻译整理,序言、
WCF
设计通用设计规范、设计要点。并给出注释。注释内容于括号内。下一部分会整理,服务契约、数据契约、实例管理的内容。这里放出的是中英文对照版。方便大家学习。最后翻译结束,我会整理一个纯中文版放出。如有错误,请批评指正。欢迎留言交流。
序言
对于一次成功的产品交付来说,完整编码规范至关重要。这个规范可以帮助强化一些通用的最佳实践准则,并避免犯错,方便整个团队理解这些知识。通常,编码规范都是相当的繁琐,动辄上百页,内容详细叙述每个编码规则的基本原理。虽然这比没有规范要好的多,但是通常开发人员难以理解和掌握。相反,《
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:
这些原则不是必须的。
a)
Services are interoperable.
服务是可互操作的
b)
Services are scale-invariant.
服务是可以伸缩的
c)
Services are available.
服务是可用的
d)
Services are responsive.
服务是可以相应的
e)
Services are disciplined and do not block their clients for long.
服务是遵守规则的,不能长时间阻塞客户端进程。
Essentials
设计要点
1.
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.
不要给服务类提供参数化的构造函数,除非其是
singleton
单例模式,并且确定宿主。
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:
为契约定义有意义的命名空间。暴露的外部服务,使用公司的
URL
或
URN
,并附上年月日等支持版本化。
例如:
[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.
当使用
Visual Studio 2010
生成客户端代理的时候,记得释放代理。(这里应该是重写IDispose的Dispose方法,释放非托管资源。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.
通常要关闭或者销毁(
close
或
dispose proxy
)代理实例。(客户端代理包含网络连接等珍贵资源,继续释放,调用Close方法或者在Using体力声明客户端代理即可)
13. When using discovery, prefer dynamic addresses.
当使用服务发现机制的时候,推荐动态地址。(动态定位服务地址是
WCF
服务发现的优势)
14. When using discovery, do support the metadata exchange endpoint over TCP.
当使用服务发现机制的时候,记得暴露支持
TCP
元数据交换的终结点。(这里指的是
Ad-Hoc
模式,适用于企业局域网,提高数据交换速度)
15. When using discovery, avoid cardinality of “some”.
当使用服务发现机制的时候,避免使用不确定的基数
(WCF4.0
里,查找终结点的个数,这里明确数目,
FindCriteria.MaxResults = 1
)
备注:
WCF4.0服务发现的文章,大家有兴趣可以参考:
1. WCF4.0新特性体验(10):服务发现WS-Discovery之简单的Ad hoc Service Discovery
2. WCF4.0新特性体验(11):服务发现WS-Discovery之设定FindCriteria
3. WCF4.0新特性体验(12):服务发现WS-Discovery之Managed Service Discovery