项目经验的零星总结

 
一.   三层架构的理解与应用
1.1何为三层架构
   标准的三层架构是用户接口层(UI),商务逻辑层(BL),数据库层(DL).
   1.1.1用户接口层负责用户的输入(鼠标,键盘,扫描仪等等),输出(显示器界面,打印机等等),界面逻辑(实际映射的是工作流,它决定了操作后页面的跳转.)业务实体的实体数据在此产生.
   1.1.2 商务逻辑层关注的是商务(业务)逻辑,它将业务逻辑映射到数据控制属性和实体属性中去. 在此将输入数据按照业务逻辑的含义进行处理,然后传入数据库层进行存储或者返回相应数据.它反映的是业务操作对数据产生的影响:根据该操作的业务逻辑意义并结合界面层对该数据的更改重新计算数据的控制属性和实体属性..业务实体的控制属性在此层产生。
              
   1.1.3 数据库层关注的是数据库逻辑:建立业务实体到数据库实体的映射,然后安全,完整地将数据存储以及取出.数据库实体在此产生,它也要知道业务实体.数据库访问层的意义就是向BL提供业务对象的增，删，改，查功能。
 
难点在于区分页面逻辑/业务逻辑/数据库逻辑,业务实体/数据库实体.只有很好的区分他们,并且在接口层隔离,才能做到层与层之间的低耦合,尽量将改变限制在一个层里.
    1.2 三层架构并不是完美的,应该灵活运用,有时商务逻辑很简单的情况下完全可以只用两层;也可以借鉴duwamish中推荐的Façade模式,利用一个中间层来将简单逻辑与复杂逻辑区分开,分别处理.
    1.3三层之间的数据传递.
        输入时:界面层记录输入的数据(一个简单的判断原则是若没有实行计算机化时用户需要输入的数据以及计算机化需要额外输入的数据,主要是业务上需要的信息)
                   ,逻辑层根据业务逻辑处理数据(主要是逻辑控制信息),数据库层存储处理后的数据.
       三层之间采用业务实体进行传输,应将每个业务实体分为三部分:界面层输入部分,业务层控制部分,数据库层控制部分
二.   系统边界的定义,数据流的起点和终点
系统边界一定要定义清楚,这关系到数据流的起点和终点,计算机算法中要求算法是有穷的,若是不满足上面两条,就可能造成工作流的无限循环,甚至无法设计.
三.   设计比代码重要,需求比设计先行,加强沟通
四.   设计中接口数据和方法应该尽量抽象,尽可能保持模块内的各类似方法结构一致.
(待续..........