ServiceContract
契约与实现相分离
在项目中，一般都是有高程或架构师定义好服务契约，然后由程序员来实现这些服务契约。服务契约和实现最好是放在不同的项目中。这样的分离有什么好处呢？第一个，有的时候我们甚至想将服务的实现部分作为一个独立的部分去部署，比如在我曾经的一个项目中，用户要求软件脱机也能使用，在这个项目中WCF服务主要就是提供数据访问，我们的解决办法就是在客户端也部署一个实现服务的程序集，但这里并不使用WCF：
当然，你将服务契约和实现放在一起也可以这样部署，一点问题都没有，但在实现类上标有很多[ServiceContract]和[OperationContract]，总有一点感觉这个东西职责不明一样（纯粹个人感觉而已）。
第二个优势是，就可以有很好的分工了。对于服务契约我觉得不是Team里的每个人都可以添加或修改的，只允许特定的人，比如架构师来做这件事情，作为程序员你只需要实现给定的契约就可以了，还有就是我在interface中定义的方法实现契约的人是必须实现的，不然编译都编译不过去，这也是一个强制性措施。
第三个优势是，一般客户端和服务器端都共享契约，那么我们可以在客户端和服务器端都引用这个契约的项目，减少代码量。
有了这些好处，我们就在interface中加[ServiceContract]，在具体的类中实现这些interface。
操作契约的重载
使用C#这些面向对象的语言实现服务的时候，我们就得面临这样一个问题：重载。C#是允许重载的，但是重载属于面向对象的范畴，而WCF是SOA，在这里没有重载。在这里OperationContract为我们提供了一个Name属性，我们可以使用同名的方法，但是使用这里的Name区分开来。比如我们要编写一个用户验证的服务，我们可以使用username/password登陆系统或使用userid(会员编号)/password登陆系统：
interface IUserService
3: {
//使用重载，但是使用Name加以区分
5:
//使用username/password登陆
)]
string password);
//使用userid/password登陆
)]
string password);
12: }