案例描述：然而，随着项目复杂度和规模的增长，这种集中式的做法可能会导致控制器层变得过于臃肿和混乱，影响项目的可维护性和可扩展性。为了解决这个问题，本案例采用三层架构模式进行了重构，将业务逻辑从控制器中分离，并通过依赖注入技术实现了代码的解耦，从而提高了代码的清晰度和可维护性。
01案例实现
将代码的职责明确划分为数据访问层、业务逻辑层和表现层，这样的分离目的是增强应用的可维护性、可测试性和可扩展性。以下是一个简化的示例。
1. 数据访问层
定义一个接口及其实现类来管理博客文章的数据交互，这通常涉及数据库操作。接口声明了数据访问的方法，而实现类则提供了这些方法的具体实现，与数据库进行通信。
(1) 定义接口。
PostRepository接口定义了一组操作博客文章数据的方法，这些方法通常用于与数据存储(如数据库)进行交互。接口包含以下方法。getAllPosts()： 返回一个包含所有博客文章的列表。getPostById(Long id)： 根据提供的文章ID返回一个博客文章对象。createPost(Post post)： 创建一个新的博客文章，并将其添加到数据存储中。deletePost(Long id)： 根据提供的文章ID从数据存储中删除博客文章。这个接口为数据访问层提供了一个抽象层，允许不同的实现类以不同的方式(例如，使用不同类型的数据库)来实现这些数据操作，同时保持业务逻辑层的一致性。示例代码如下：
(2) 接口的实现。
InMemoryPostRepository类是PostRepository接口的一个实现，它提供了一个简单的内存数据存储来管理博客文章。这个实现使用了一个static的ArrayList来模拟数据库中的数据表。示例代码如下：
这个实现没有使用真正的数据库，而是在内存中进行操作，适用于测试或小型应用。在实际应用中，可能会使用JPA、MyBatis或其他ORM(对象关系映射)工具来实现数据访问层的逻辑，与数据库进行交互，这在第4章中会详细介绍。
2. 业务逻辑层
PostService类是一个服务组件，用于封装与博客文章相关的业务逻辑。它通过依赖注入获得数据访问层的PostRepository实例，并提供了一系列方法来执行获取、创建、删除文章的操作。示例代码如下：
- 表现层
表现层是应用程序中与用户直接交互的部分，主要负责处理HTTP请求、生成响应，以及展示用户界面。PostController类作为表现层的组件，通过依赖PostService对象来处理业务逻辑，避免了直接操作数据的细节，从而简化了控制器的职责并实现了更清晰的职责划分。这种设计使得PostController类专注于用户交互，而将数据处理委托给服务层。示例代码如下：
其中:
getAllPosts()方法处理GET请求，返回所有文章的列表。
getPostById(@PathVariable Long postId)方法处理带有特定文章ID的GET请求，返回单个文章或404错误。
createPost(@RequestBody Post newPost)方法处理POST请求，创建并返回新文章。
deletePost(@PathVariable Long postId)方法处理DELETE请求，根据文章ID删除文章，并返回204状态或404错误。02案例总结
通过分层架构设计，各个层次的职责得以明确。表现层专注于处理HTTP请求和响应，确保与用户的交互顺畅； 业务逻辑层则承担起执行核心业务规则的任务； 而数据访问层专门负责与数据存储进行交互。通过依赖注入，各层之间的耦合度得以降低，这不仅提升了代码的可测试性，也增强了系统的可维护性。在后续章节中，读者将会看到如何轻松地将数据源切换到实际的数据库，进一步提升系统的实用性。
