具体解释三层架构图

 PS: 在看三层架构的时候,找的了一个我感觉不错的材料,里面有例如以下一张图,打算具体的解释一下这张图,也总结一下三层的知识

  

一、系统各层次职责

     1.UIUser Interface)层的职责是数据的展现和採集,数据採集的结果通常以Entity object提交给BL层处理Service Interface側层用于将业务或数据资源公布为服务(如WebServices)。

    2.BLBusiness Logic)层的职责是按预定的业务逻辑处理UI层提交的请求。

    (1Business Function 子层负责基本业务功能的实现。

    (2Business Flow 子层负责将Business Function子层提供的多个基本业务功能组织成一个完整的业务流(Transaction仅仅能在Business Flow 子层开启。)

    3ResourceAccess层的职责是提供全面的资源訪问功能支持,并向上层屏蔽资源的来源。

  (1BEMBusiness Entity Manager)子层採用DataAccess子层和ServiceAccess子层来提供业务须要的基础数据/资源訪问能力。

  (2DataAccess子层负责从数据库中存取资源,并向BEM子层屏蔽全部的SQL语句以及数据库类型差异。

    DB Adapter子层负责屏蔽数据库类型的差异。

    ORM子层负责提供对象-关系映射的功能。

    Relation子层提供ORM无法完毕的基于关系(Relation)的数据訪问功能。

  (3ServiceAccess子层用于以SOA的方式从外部系统获取资源。

         注:Service Entrance用于简化对Service的訪问,它相当于Service的代理,客户直接使用Service Entrance就能够訪问系统公布的服务。Service      Entrance为特定的平台(如Java.Net)提供强类型的接口,内部可能隐藏了复杂的參数类型转换。

  (4ConfigAccess子层用于从配置文件里获取配置object或将配置object保存倒配置文件。

    4Entity側层跨越UI/BEM/ResourceManager层,在这些层之间传递数据。Entity側层中包括三类Entity,例如以下图所看到的:

  

二、Aspect

    Aspect贯穿于系统各层,是系统的横切关注点。通常採用AOP技术来对横切关注点进行建模和实现。

    1Securtiy Aspect:用于对整个系统的Security提供支持。

    2ErrorHandling Aspect:整个系统採用一致的错误/异常处理方式。

    3Log Aspect:用于系统异常、日志记录、业务操作记录等。

 

三、规则

    1.系统各层次及层内部子层次之间都不得跨层调用。

    2Entity object 在各个层之间传递数据。

    3.须要在UI层绑定到列表的数据採用基于关系的DataSet传递,除此之外,应该使用Entity object传递数据。

    4.对于每个数据库表(Table)都有一个DB Entity class与之相应,针对每个Entity class都会有一个BEM Class与之相应。

    5.有些跨数据库或跨表的操作(如复杂的联合查询)也须要由对应的BEM Class来提供支持。

    6.对于相对简单的系统,能够考虑将Business Function子层和Business Flow 子层合并为一个。

    7UI层和BL层禁止出现不论什么SQL语句。

 

四、错误与异常

         异常能够分为系统异常(如网络突然断开)和业务异常(如用户的输入值超出最大范围),业务异常必须被转化为业务运行的结果。

    1DataAccess层不得向上层隐藏不论什么异常(该层抛出的异常差点儿都是系统异常)。

    2.要明白区分业务运行的结果和系统异常。比方验证用户的合法性,假设相应的用户ID不存在,不应该抛出异常,而是返回(或通过out參数)一个表示验证 结果的枚举值,这属于业务运行的结果。可是,假设在从数据库中提取用户信息时,数据库连接突然断开,则应该抛出系统异常。

    3.在有些情况下,BL层应依据业务的须要捕获某些系统异常,并将其转化为业务运行的结果。比方,某个业务要求试探指定的数据库是否可连接,这时BL就须要将数据库连接失败的系统异常转换为业务运行的结果。

    4UI(包含Service)除了从调用BL层的API获取的返回值来查看业务的运行结果外,还须要截获全部的系统异常,并将其解释为友好的错误信息呈现给用户。

 

五、项目组织目结构

    以BAS系统为例。

     1.主文件夹结构:

 

     2.命名空间命名:每一个dll的根命名空间即是该dll的名字,如EAS.BL.dll的根命名空间就是EAS.BL。每一个根命名空间以下能够依据需求的 分类而添加子命名空间,比方,EAS.BL的子空间EAS.BL.OrderEAS.BL.Permission分别处理不同的业务逻辑。

    3.包括众多子项目的庞大项目的物理组织:

 

核心子项目Core的位置:

 

 

Core子项目中包括一些公共的基础设施,如错误处理、权限控制方面等。

六、公布服务与服务回调

EAS系统为例。

 

     1.同UI层的Page一样,服务也不同意抛出不论什么异常,而是应该以返回错误码(int型,1表示成功,其他值表示失败)的形式来表明服务调用出现了错误,假设方法有返回值,则返回值以out參数提供。

     2.假设BAS系统提供了WebServiceRemoting)服务,则BAS必须提供BAS.Entrance.dll。 BAS.Entrance.dll封装了与BAS服务交换信息的通信机制,客户系统仅仅要通过BAS.Entrance.dll就能够很简便地訪问BAS 提供的服务。

     3.假设BAS须要通过WebServiceRemoting)回调客户系统,则必须提供只定义了接口的BAS.CallBack.dll,客户系统将引用该dll,实现当中的接口,并将其公布为服务,供BAS回调。

     4.当WebService的參数或返回值须要是复杂类型――即架构图中的Service Entity,则Service Entity应该在相应的BAS.EntranceParaDef.dllBAS.CallBackParaDef.dll中定义。 WebService定义的方法中的复杂类型应该使用Xml字符串取代(注意,EntranceCallBack接口相应服务的方法的參数是强类型 的),而Xml字符串和复杂类型对象之间的转换应当在BAS.Entrance.dllBAS.CallBack.dll中实现。

 

 

 

 

posted @ 2015-05-20 13:25  zfyouxi  阅读(2426)  评论(0编辑  收藏  举报