轻量级架构设计之分层的魅力

 

     介绍一下手头一个系统的软件结构，先附上图：

 

 

大概分为5层：

 

视图层：
     作用：系统和用户进行交互，分离出来，是因为系统修改了界面无需修改业务，甚至于

可以把改写为wap在手机浏览器进行操作。
     组成部分：web组件、struts标签等

应用层：

      作用：对业务的复杂性进行了封装，视图层的调用者无需知道业务逻辑的具体细节，它仅仅知道使用就可以了，作为系统的协调者，接受数据，对数据进行的操作，操作之后所要到达的视图。

      组成部分：控制器、pojp facade（看下方注解）

领域层：

      作用：业务逻辑层，在这里实现所有的业务逻辑，以及建模中抽象出来的模型，严格的话可以再用聚合的思路抽象出一些业务逻辑的协调者（比如：转账的时候，调用了减去余额和专家余额2个类，那就可以抽象出一个协调类，负责一起调用这2个类）

      组成部分：业务逻辑、模型、业务逻辑协调者（业务 facade）

持久层：

      作用：就是把模型、实体等的对象持久化到硬盘

      组成部分：hibernate、DAO等

公共基础层：

      作用：系统中可以作为基础功能的一些集合

      组成：一些可以被大家所公用的而且可以重复利用的组件（如上传下载等）

总结：

      这里的“公共基础层”其实不算是一层，它只是一个特殊的包，专门为上层提供一些比如上传下载、邮件收发等共有组件使用的封装。

 

注解：

POJO FACADE：

引自《POJOs IN ACTION》中的解析，比如：现在汽车是件复杂的机器。它包含

各种机械部件，如：气缸、轮胎等，也许还提供和有足以把飞船送上月球的接受能力，不过对

于用户来说，大部分复杂性都不可见，要开动汽车，我们只需和车钥匙、方向盘、脚刹和变速

档打交道。这些简单的控制装置封装了汽车内部的复杂性。同样，对于业务逻辑的客户表示层

（和控制器）来说，我们也需要隐藏业务逻辑的复杂性。POJO façade在这里其实就是领域模

型的使用者。因为领域模型最好是用POJO方式编码（即不依赖于特定的框架，如Spring、EJB

，这是业务逻辑编码的准则）。