分层模式是最通用的架构,也被叫做N层架构模式(n-tier architecture pattern).这也是Java EE应用经常采用的标准模式.基本上都知道它.这种架构模式非常适合传统的IT通信和组织结构,很自然地成为大部分应用的第一架构选择.
模式描述
在分层架构中的组件被划分成几个层,每个层代表应用的一个功能.分层架构本身没有规定要分成多少层,大部分的应用会分成表现层,业务层,持久层和数据库层.小的应用有时候会将业务层和持久层合在一起,更大规模的应用可能会划分更多的层,比如调用外部服务的层.
每一层都有特定的角色和职能.各层实现的功能如下:
- 表现层(presentation):用户界面,负责视觉和用户互动
- 业务层(business):实现业务逻辑
- 持久层(persistence):提供数据,SQL 语句就放在这一层
- 数据库(database):保存数据
架构考量
分层架构是一个可靠的通用的架构,对很多应用来说,如果你不确定哪种架构适合你的应用,可以用它作为一个初始架构.第一个要注意的是污水池反模式(architecture sinkhole anti-pattern).这个反模式是这样的,请求流简单的穿过几个层,每层里面基本没有做任何业务逻辑,或者做了很少的业务逻辑,比如一些JavaEE例子,业务逻辑层只是简单的调用了持久层的接口,本身没有什么业务逻辑.每一层或多或少都有可能遇到这样的场景.关键是分析这样的请求的百分比是多少.80-20原则可以帮助你决定是否正在遇到污水池反模式,如果你的请求超过20%,你应该考虑让一些层变成开放的.
另一个需要考虑的是分层架构可能会让你的应用变得庞大,即使你的展示层和业务层可以独立发布（比如展示层使用单页技术框架AngularJS, EmberJS）.它的确会带来一些潜在的问题,比如分布模式复杂,健壮性下降,可靠性,性能和规模等.
模式分析
- 总体灵活性: 低
- 发布易用性:低
- 可测试性: 高
- 性能:低
- 规模扩展性: 低
- 开发容易度: 高
优点
- 结构简单,容易理解和开发
- 不同技能的程序员可以分工,负责不同的层,天然适合大多数软件公司的组织架构
- 每一层都可以独立测试,其他层的接口通过模拟解决
缺点
- 一旦环境变化,需要代码调整或增加功能时,通常比较麻烦和费时
- 部署比较麻烦,即使只修改一个小地方,往往需要整个软件重新部署,不容易做持续发布
- 软件升级时,可能需要整个服务暂停
- 扩展性差.用户请求大量增加时,必须依次扩展每一层,由于每一层内部是耦合的,扩展会很困难
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！