zoukankan      html  css  js  c++  java
  • 【转载】我的架构经验小结(三)-- 深入三层架构

    我的架构经验小结(三)-- 深入三层架构

       在 我的架构经验小结(二)-- 关于三层架构 一文中,已经比较深入的介绍过三层架构方面的一些经验了,现在,我们来使用一个更小的比例尺来近距离观察我所理解的三层架构。

    一.三层架构图

     

    二.系统各层次职责
    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层应根据业务的需要捕获某些系统异常,并将其转化为业务执行的结果。比如,某个业务要求试探指定的数据库是否可连接,这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。
    4.UI层(包括Service层)除了从调用BL层的API获取的返回值来查看业务的执行结果外,还需要截获所有的系统异常,并将其解释为友好的错误信息呈现给用户。

    六.项目组织目结构
     以BAS系统为例。
    1.主目录结构:
     
    2.命名空间命名:每个dll的根命名空间即是该dll的名字,如EAS.BL.dll的根命名空间就是EAS.BL。每个根命名空间下面可以根据需求的分类而增加子命名空间,比如,EAS.BL的子空间EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。
    3.包含众多子项目的庞大项目的物理组织:
     
    核心子项目Core的位置:

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

    七.发布服务与服务回调
    以EAS系统为例。
     
    1.同UI层的Page一样,服务也不允许抛出任何异常,而是应该以返回错误码(int型,1表示成功,其它值表示失败)的形式来表明服务调用出现了错误,如果方法有返回值,则返回值以out参数提供。
    2.如果BAS系统提供了WebService(Remoting)服务,则BAS必须提供BAS.Entrance.dll。BAS.Entrance.dll封装了与BAS服务交换信息的通信机制,客户系统只要通过BAS.Entrance.dll就可以非常简便地访问BAS提供的服务。
    3.如果BAS需要通过WebService(Remoting)回调客户系统,则必须提供仅仅定义了接口的BAS.CallBack.dll,客户系统将引用该dll,实现其中的接口,并将其发布为服务,供BAS回调。
    4.当WebService的参数或返回值需要是复杂类型――即架构图中的Service Entity,则Service Entity应该在对应的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定义。WebService定义的方法中的复杂类型应该使用Xml字符串代替(注意,Entrance和CallBack接口对应服务的方法的参数是强类型的),而Xml字符串和复杂类型对象之间的转换应当在BAS.Entrance.dll或BAS.CallBack.dll中实现。

     

  • 相关阅读:
    康复计划
    Leetcode 08.02 迷路的机器人 缓存加回溯
    Leetcode 38 外观数列
    Leetcode 801 使序列递增的最小交换次数
    Leetcode 1143 最长公共子序列
    Leetcode 11 盛水最多的容器 贪心算法
    Leetcode 1186 删除一次得到子数组最大和
    Leetcode 300 最长上升子序列
    Leetcode95 不同的二叉搜索树II 精致的分治
    Leetcode 1367 二叉树中的列表 DFS
  • 原文地址:https://www.cnblogs.com/fx2008/p/2261949.html
Copyright © 2011-2022 走看看