分布式架构

 

 

 

1. 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

1. 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. 亲，总有一款适合您！

1. 3.  设计总结：

3.1.  原来的开发模式，一个实体承担了过多职责（即当PO、又当BO），属性会随业务的成长越来越臃肿（变相增加维护成本）就很可能会发生此现象：例如用户（UI层）只需要喝牛奶，而维护的开发误把奶牛（Data层PO）和空瓶子（Biz层BO）打包给用户，用户只好拿奶牛自己挤到瓶子里喝。实际上用户只关心喝的奶而不是具体生产过程，这也是实体职责分离的好处。

3.2.  不管是MVC，MVP还是MVVM都是职责分离解耦，只是实现方式不同。虽然实现方式有很多途径，但具体还要看公司的策略。

3.3.  个人推荐EF + WCF（WS是WCF的子集） + MVP&MVVM 这种组合模式开发。好的开发模式可以帮助开发更效率地编写高健壮性的代码，而不是把开发变“傻”。