- 1. 实体职责：
1.1. PO（Persistant Object） 例如EntityFramework中生成的数据实体，映射数据库中的表结构；
1.2. BO（Business Object） 对上层暴露的业务实体。架构师在开发初期定义的业务接口中所用到的实体；
1.3. DTO（Data Transfer Object） 分布式服务（WebService/WCF）暴露的契约实体；
1.4. VO（View Object） 例如ASP.NET MVC中的V（UI实体）；
1.5. 参考：http://www.cnblogs.com/BigTall/archive/2007/12/12/991779.html
- 2. 项目结构：
2.1. Solution主要放公共、第3方的一些源；Nuget的程序包在项目跟目录下packages文件夹中。
2.2. Core分为Contract和Entity，其中Contract定义Service端对外暴露的契约接口，Entity定义Contract中用到的契约实体（DTO）；Contract按业务划分文件夹如下图所示：
Entity的目录结构：
Contract的参数和返回值都定为DTO，参数DTO就放在对应业务文件夹中parameter文件夹下，返回值DTO就在Result文件夹下；这些是由架构师定下来的，开发只需按照接口去编码。
PS: 因为服务不能有重载方法，所以把参数都定义到一个DTO实体里，其次如果用重载的方式，在业务变更时入参顺序发生变化时就不受控制。
2.3. Service是对Core的具体实现，如果不需要分布式的服务，那么Service的顶层可定义为逻辑层，同样Core就定义为BO。
2.3.1. 实体转换过程：PO - BO - DTO
2.3.2. DataAccess为数据访问；
2.3.3. BusinessLogic 为业务逻辑的实现；
2.3.4. Service 为服务Contract的实现；
2.3.5. Host 为服务宿主，可以为站点也可以为window服务等；
2.4. Portal端可与Service端在不同的解决方案（项目分离）；Portal分为FacadeModel、ViewObject和WebUI，其中FacadeModel与多个Service交互并对上层暴露ViewObject如下图所示：
WebUI通过ViewObject与FacadeModel做呈现和回调，应付很多实际的场景，Remoting Windows Services，WebServices，Restful Services
2.5. 此小节选看
2.5.1. 如果后台UI比较复杂可以考虑使用ASP.NET MVC，如果必须使用ASP.NET WebForm推荐采用MVP模式如下图所示：
参考：
http://www.cnblogs.com/bluewater/archive/2006/12/11/589214.html
http://msdn.microsoft.com/zh-cn/magazine/ff955232.aspx
2.5.2. 如果必须使用Ajax可以考虑使用knockoutjs的MVVM模式，
参考：http://knockoutjs.com/
2.5.3. 亲，总有一款适合您！
- 3. 设计总结：
3.1. 原来的开发模式，一个实体承担了过多职责（即当PO、又当BO），属性会随业务的成长越来越臃肿（变相增加维护成本）就很可能会发生此现象：例如用户（UI层）只需要喝牛奶，而维护的开发误把奶牛（Data层PO）和空瓶子（Biz层BO）打包给用户，用户只好拿奶牛自己挤到瓶子里喝。实际上用户只关心喝的奶而不是具体生产过程，这也是实体职责分离的好处。
3.2. 不管是MVC，MVP还是MVVM都是职责分离解耦，只是实现方式不同。虽然实现方式有很多途径，但具体还要看公司的策略。
3.3. 个人推荐EF + WCF（WS是WCF的子集） + MVP&MVVM 这种组合模式开发。好的开发模式可以帮助开发更效率地编写高健壮性的代码，而不是把开发变“傻”。