三层架构图4.pdf

⼀. 三层架构图
 
 
 ⼆．系统各层次职责
 1.UI （User Interface ）层的职责是数据的展现和采集，数据采集的结果通常以Entity object提交给BL层处理。Service Interface侧 层⽤于将业务或数据资源发布为服务（如WebServices ）。
 2.BL （Business Logic ）层的职责是按预定的业务逻辑处理UI层提交的请求。
 （1）Business Function ⼦层负责基本业务功能的实现。
 （2 ）Business Flow ⼦层负责将Business Function⼦层提供的多个基本业务功能组织成⼀个完整的业务流。（Transaction只能在 Business Flow ⼦层开启。）
 3 ．ResourceAccess层的职责是提供全⾯的资源访问功能⽀持，并向上层屏蔽资源的来源。
 （1）BEM （Business Entity Manager ）⼦层采⽤DataAccess⼦层和ServiceAccess⼦层来提供业务需要的基础数据/资源访问能 ⼒。
 （2 ）DataAccess⼦层负责从数据库中存取资源，并向BEM⼦层屏蔽所有的SQL语句以及数据库类型差异。
 DB Adapter⼦层负责屏蔽数据库类型的差异。
 ORM⼦层负责提供对象－关系映射的功能。
 Relation⼦层提供ORM⽆法完成的基于关系（Relation ）的数据访问功能。
 （3 ）ServiceAccess⼦层⽤于以SOA的⽅式从外部系统获取资源。
 注：Service Entrance⽤于简化对Service的访问，它相当于Service的代理，客户直接使⽤Service Entrance就可以访问系统发布的 服务。Service Entrance为特定的平台（如Java、.Net）提供强类型的接⼜，内部可能隐藏了复杂的参数类型转换。
 （4 ）ConfigAccess⼦层⽤于从配置⽂件中获取配置object或将配置object保存倒配置⽂件。
 4 ．Entity侧层跨越UI/BEM/ResourceManager层，在这些层之间传递数据。Entity侧层中包含三类Entity ，如下图所⽰：
 
 
 三．Aspect
 Aspect贯穿于系统各层，是系统的横切关注点。通常采⽤AOP技术来对横切关注点进⾏建模和实现。
 1．Securtiy Aspect ：⽤于对整个系统的Security提供⽀持。
 2 ．ErrorHandling Aspect ：整个系统采⽤⼀致的错误/异常处理⽅式。
 3 ．Log Aspect ：⽤于系统异常、⽇志记录、业务操作记录等。
 
 四．规则
 1．系统各层次及层内部⼦层次之间都不得跨层调⽤。
 2 ．Entity object 在各个层之间传递数据。
 3 ．需要在UI层绑定到列表的数据采⽤基于关系的DataSet传递，除此之外，应该使⽤Entity object传递数据。
 4 ．对于每⼀个数据库表（Table ）都有⼀个DB Entity class与之对应，针对每⼀个Entity class都会有⼀个BEM Class与之对应。
 5 ．有些跨数据库或跨表的操作（如复杂的联合查询）也需要由相应的BEM Class来提供⽀持。
 6 ．对于相对简单的系统，可以考虑将Business Function⼦层和Business Flow ⼦层合并为⼀个。
 7 ．UI层和BL层禁⽌出现任何SQL语句。
 
 五．错误与异常
 异常可以分为系统异常（如⽹络突然断开）和业务异常（如⽤户的输⼊值超出最⼤范围），业务异常必须被转化为业务执 ⾏的结果。
 1．DataAccess层不得向上层隐藏任何异常（该层抛出的异常⼏乎都是系统异常）。
 2 ．要明确区分业务执⾏的结果和系统异常。⽐如验证⽤户的合法性，如果对应的⽤户ID不存在，不应该抛出异常，⽽是返回 （或通过out参数）⼀个表⽰验证 结果的枚举值，这属于业务执⾏的结果。但是，如果在从数据库中提取⽤户信息时，数据库 连接突然断开，则应该抛出系统异常。
 3 ．在有些情况下，BL层应根据业务的需要捕获某些系