阅读笔记(二)——分层模式

分层架构，顾名思义，就是将一个不能解决，复杂的问题进行切分，方便我们对其进行处理。

模式描述：

对于一般的应用，系统都会被分为表现层，业务层，持久层和数据库层.

 

大致的业务流程如下：

表现层：相当于点单时的小哥，负责与用户交互

业务层：用来实现业务逻辑，也就是炒菜

持久层：负责提供数据，也就是食材

数据库：保存数据

 

关键概念：层隔离

 

注意每一层都是封闭的.这意味着Request必须经过每一层才能到达最底下一层. 层隔离的概念意味着你对任何一层的改变都不会影响其它层,这很好理解.层隔离也意味着一个层的组件并不会了解其它层的实现,或者知道很少. 比如业务层不需知道你持久层是由hibernate还是mybatis实现的.

结合上面的例子，也可以知道。你换一个前台小哥是不会影响其他层次的。当然你换一个大妈，得问大爷答应不答应。

 

架构的考量

• 总体灵活性: 低
• 发布易用性:低
• 可测试性: 高
• 性能:低
• 规模扩展性: 低
• 开发容易度: 高

 

优缺点

优点

结构简单,容易理解和开发
不同技能的程序员可以分工,负责不同的层,天然适合大多数软件公司的组织架构
每一层都可以独立测试,其他层的接口通过模拟解决

缺点

一旦环境变化,需要代码调整或增加功能时,通常比较麻烦和费时
部署比较麻烦,即使只修改一个小地方,往往需要整个软件重新部署,不容易做持续发布
软件升级时,可能需要整个服务暂停
扩展性差.用户请求大量增加时,必须依次扩展每一层,由于每一层内部是耦合的,扩展会很困难

规则

  1．系统各层次及层内部子层次之间都不得跨层调用。
    2．Entityobject 在各个层之间传递数据。
    3．需要在UI层绑定到列表的数据采用基于关系的DataSet传递，除此之外，应该使用Entityobject传递数据。
    4．对于每一个数据库表（Table）都有一个DB Entity class与之对应，针对每一个Entityclass都会有一个BEMClass与之对应。
    5．有些跨数据库或跨表的操作（如复杂的联合查询）也需要由相应的BEM Class来提供支持。
    6．对于相对简单的系统，可以考虑将Business Function子层和Business Flow 子层合并为一个。
    7．UI层和BL层禁止出现任何SQL语句。

 

小结

分层式设计可以达至如下目的：分散关注、松散耦合、逻辑复用、标准定义。一个好的分层式结构，可以使得开发人员的分工更加明确。一旦定义好各层次之间的接口，负责不同逻辑设计的开发人员就可以分散关注，齐头并进。

 

 

参考文章：

https://blog.csdn.net/e5Max/article/details/81627569