从包图分析逻辑层架构

        设计软件体系架构时，分层式结构是一种常见，也是很重要,有效的一种结构。其优点就不再赘述.

        今天由在UML下的三层架构的包图入手，讨论一下业务逻辑层的具体架构.

        业务逻辑层的设计对于一个支持可扩展的架构非常关键，因为它扮演了两个不同的角色。对于数据访问层而言，它是调用者；对于表示层而言，它却是被调用者。依赖与被依赖的关系都纠结在业务逻辑层上，如何实现依赖关系的解耦，则是除了只是实现业务逻辑之外很重要的任务。

        首先，熟悉几个基本概念。

        （1）包图：

        创建一个包图是为了：

        1、描述需求高阶概述。
        2、描述设计的高阶概述。
        3、在逻辑上把一个复杂的图模块化。
        4、组织源代码。

        简单来说，包就是从宏观上了解软件的架构，即没个程序集或模块之间的联系，从而为详细设计提供总体框架。

        

            （2） 程序集

        定义：
           1、程序集是一个或多个托管模块，以及一些资源文件的逻辑组合。
           2、程序集是组件复用，以及实施安全策略和版本策略的最小单位。
           3、程序集是包含一个或者多个类型定义文件和资源文件的集合。

        程序集有两种物理表现：

           1、可执行程序集：存在一个用于表示EXE的文件，这个文件是程序集的入口点。
           2、提供功能的程序集：存在一个用于表示DLL的文件，这个文件是程序集的入口点。      

        程序集的独立性较高,使用简单,只需进行相应的引用,并且可以进行并行加载,同一个DLL的不同版本可以在同一个系统上同时使用,
          
        （3）程序集与包的关系

           1、UML中的包图中的一个包在vs中基本上是代表一个程序集,即每个包可以生成一个dll或exe文件.包与包之间的关系则表明了系统中程序集之间的引用关系。

           2、从本质上讲，包是一个命名的声明部分，vs中的一个包（即文件夹）代表一层命名空间，命名空间完全独立于程序集，一个程序集中可以有多个（不同名称的）包，即多个（不同的）命名空间，包中还可以嵌套包。 一个命名空间也可以分布在多个程序集中
           3、 命名空间只是类名的一种扩展，它属于类名的范畴。包的实例没有语义,仅在建模时有意义,而不必转换到系统中。

                                                                                                                                                                                                                                                                     

 

                       进入正题，由于仅仅讨论三层中的业务逻辑的几种架构，所以并不涉及工厂或接口等，仅是最简单的三层。

               第一个包图：

 

     

                 这是最标准，最经典的三层架构，业务层处于数据访问层与表示层中间，起到了数据交换中承上启下的作用。这样所有的业务逻辑都在一个程序集中，即最终生成一个dll文件。

            如果在系统逻辑的设计中，有很多较小的逻辑判断经常被用到，为能做到良好的复用性，应该怎么做?单独提出来是肯定的，不然不能灵活复用，那么提到哪里？

            这就需要看这部分经常被复用的业务是否可能经常变动。    

            (1)如果经常或可能有变动,升级可能性较大。则使用下图架构。

                这种架构将b层分成两部分,将容易变动的和比较固定的业务分开。这样，等业务发生变化，就只需改动其中一个Bll的DLL文件，而不用涉及到整个b层。   

    

 

                        如果感觉上图的做法对界面层暴露的信息较多，会加重页面层的信息量，则可以在界面层和具体业务层之间再加一层，就相当于加了一个外观模式，将具体的业务逻辑进行汇总和封装，外部只提供给界面一个统一的接口。如下图:

 

   

 

 

                   （2）如果业务基本固定，修改的几率不大，则仅仅需要考虑良好复用即可，而没有必要将这部分业务归成一个单独的程序集。 而只需要作为业务中一个单独的类即可。或放到一个单独的文件夹下，总的来说还是一个业务程序集。因为既然没有更换业务的需求，归成一个单独的程序集，那么被用到是还需添加引用，声明Using（或Import等），给程序带来不必要的麻烦，生成一个Dll文件，直接使用是最简单的。架构图跟第一张相同，不同的是BLL层的内部结构，相当于是对BLL层的内部结构进行分类整理。

 

 

 

              下面看一个比较纠结的架构：

  

 

            教务系统起初用的就是这个架构。当时的想法是，smallBll是一些较稳定，可以被其他系统或工程复用（上面讨论的复用为本系统内部复用）的一些业务逻辑。为方便本系统内部和其他系统，就把部分b层的业务提成了一个单独的程序集。又由于这部分业务并不是独立的，属于独立业务中的一部分，所以由Bll调用smallBll而不是UI。再由于不是所有业务都用得到smallBll，所以BLL还需要不经过smallbll直接调用DAL，于是就成了上图的架构。

            后来这种架构被鉴定为不合理，原因是加了一层，却没有起到解耦的作用，使B层和D层的关系更加不明确了。所以这种不太明确的架构最好还是避免使用。

            其实架构没有非常分明的对与错，只有合适与更合适。还是要根据不同的业务和系统现状来考虑，上面的分析是基于从0开始做架构来考虑的。如果系统在开始之前，已经有可用的dll可直接使用，那架构就又是另一个样子。比如基于上图架构的教务系统在开始之前已经有了部分smallbll可用，那么个人认为上图的架构就是合理的。

            所以个人认为理论知识是死的，但架构是活的，就像数据库三范式虽然理论上很正确，但却不是所有的数据库表都适合用的。所以按照系统的具体业务和当前状态选择最合适的架构才是明智的。