多层架构

在软件工程中，多层体系结构（通常称为 n 层体系结构）是一种客户端-服务器体系结构，其中表示、应用程序处理和数据管理功能在物理上是分离的。 多层架构应用最广泛的是三层架构。

N 层应用程序架构提供了一个模型，开发人员可以通过该模型创建灵活且可重用的应用程序。 通过将应用程序分成多个层，开发人员可以选择修改或添加特定层，而不是重新设计整个应用程序。 三层架构通常由表示层、逻辑层和数据层组成。

虽然层和层的概念经常互换使用，但一种相当普遍的观点认为确实存在差异。 这种观点认为，层是构成软件解决方案的概念元素的逻辑结构机制，而层是构成系统基础设施的硬件元素的物理结构机制。 例如，一个三层解决方案可以很容易地部署在一个层上，例如在称为 RDBMS-only 架构的极端以数据库为中心的架构或个人工作站中。

层架构模式已在各种出版物中进行了描述。

在面向对象设计的信息系统的逻辑多层架构中，最常见的有以下四种：

• 表示层（也称为 UI 层、视图层、多层架构中的表示层）
• 应用层（又名服务层或 GRASP 控制器层）
• 业务层（又名业务逻辑层 (BLL)、领域逻辑层）
• 数据访问层（又名持久层、日志记录、网络和支持特定业务层所需的其他服务）

领域驱动设计一书描述了上述四层的一些常见用途，尽管它的主要重点是领域层。

如果应用程序架构在业务层和表示层之间没有明确的区别（即，表示层被认为是业务层的一部分），那么已经实现了传统的客户端-服务器（两层）模型。

更常见的约定是应用层（或服务层）被视为业务层的子层，通常封装 API 定义以显示支持的业务功能。 事实上，应用程序/业务层可以进一步细分，以强调具有不同职责的附加子层。 例如，如果使用模型-视图-演示者模式，则演示者子层可能用作用户界面层和业务/应用程序层（由模型子层表示）之间的附加层。

有些还确定了一个单独的层，称为业务基础架构层 (BI)，位于业务层和基础架构层之间。 它有时也称为低级业务层或业务服务层。 该层非常通用，可用于多个应用程序层。

基础设施层可以划分为不同的级别（高级或低级技术服务）。 开发人员通常关注基础设施层的持久化（数据访问）能力，因此只谈论持久层或数据访问层（而不是基础设施层或技术服务层）。 换句话说，另一种技术服务并不总是明确地被认为是任何特定层的一部分。

一层位于另一层之上，因为它依赖于它。 每一层都可以在没有其上层的情况下存在，并且需要其下层才能发挥作用。 另一种常见的观点是，层并不总是严格依赖于下面的相邻层。 例如，在宽松的分层系统（与严格的分层系统相反）中，一个层也可以依赖于它下面的所有层。

三层架构是一种客户端-服务器软件架构模式，其中用户界面（表示）、功能过程逻辑（业务规则）、计算机数据存储和数据访问作为独立模块开发和维护，通常在不同的平台上。

除了具有定义明确的接口的模块化软件的通常优点外，三层体系结构旨在允许三层中的任何一层都可以根据需求或技术的变化而独立升级或替换。 例如，表示层中操作系统的更改只会影响用户界面代码。