Three-tier

  • 格式:doc
  • 大小:27.95 KB
  • 文档页数:3

Three-tier:
一、概念:
Three-tier简单点说,“客户机---应用服务器-----数据服务器”,典型的情况下有多个数据服务器和多个客户端。

应用服务器也可以有多个。

应用服务器指对客户端的请求进行分析、平衡,再将其分配给数据服务器。

对数据服务器返回的结果集分析,平衡,发送至不同的客户端。

通常意义上的三层架构就是将整个业务应用划分为:表现层(Presentation layer)、业务逻辑层(Business Logic Layer)、数据访问层(Data access layer)。

区分层次的目的即为了“高内聚低耦合”的思想。

在三层体系的应用程序中,业务规则从客户端中删除并且在用户界面和数据存储之间的系统上执行。

客户端应用程序提供用户界面系统。

三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。

它是一个客户端和数据存储之间的媒介。

在这种类型的应用程序中,客户机不会直接访问数据存储系统。

这种类型的系统允许系统的任何部分被修改,而无需修改其他两部分。

由于应用程序的每部分通过接口进行通信,所以只要保持接口是相同,可以改变内部操作而不影响系统的其他部分。

一个3层架构是有以下组件层:
1.前端组件负责表示逻辑。

2.一个中间层组件负责业务逻辑。

3.后端组件负责数据访问逻辑。

这些层之间的通信仅限于以下:
∙前端只能接收来自用户的请求。

∙中间层只能接收来自前端的请求。

二、优势:
∙灵活性——通过应用程序更加明确的结构,降低了层与层之间的依赖,开发人员可以只关注整个结构中的其中某一层,三层体系结构使应用程序
更加灵活的变化。

∙可维护性——组件在一个层的变化应该不会影响任何其他层。

同样,如果不同层次需要不同的技能(如HTML / CSS是表示层,PHP / Java业务
层,SQL数据访问层)那么这些可以由独立的团队管理技能在这些特定的
区域。

∙可重用性——将应用程序分解为多个层使其容易实现可重用的组件。

单个组件在业务层,例如,可能是由多个组件在表示层、访问或甚至几个不同
的表示层(如桌面和web)在同一时间。

∙可伸缩性——一个三层架构允许跨多个服务器应用程序组件分配从而使系统更加可伸缩。

∙可靠性——一个三层架构,如果部署在多个服务器上,让它更容易增加系统的可靠性通过实现多级冗余。

∙减轻了database 服务的负担;
三、不足:
∙降低了系统的性能——如果不采用分层式结构,很多业务可以直接造访数据库,以此获取相应的数据,如今却必须通过中间层来完成。

∙有时会导致级联的修改——这种修改尤其体现在自上而下的方向。

如果在表示层中需要增加一个功能,为保证其设计符合分层式结构,可能需要
在相应的业务逻辑层和数据访问层中都增加相应的代码。

∙增加了开发成本——过度遵循开发框架,会增大项目开发的难度,并且,不合理的使用也会导致其后期维护工作繁琐。

一般遵循如下:大型企业项目-建议(强烈)采用三层框架开发
中型的-建议采用三层框架开发
小型的-不建议采用
四、案例:
模型-视图-控制器(MVC)设计模式。