在三层架构中，通常有以下三层：
表现层（Presentation Layer）：也称为控制层（Controller），负责处理用户请求和向用户展示数据。
业务逻辑层（Business Logic Layer）：也称为服务层（Service），处理业务逻辑、执行具体的业务操作。
数据访问层（Data Access Layer）：也称为持久层（DAO，Data Access Object），负责与数据库交互，进行数据的读写操作。
为了更好地组织和分离代码，你可以考虑按照以下原则来划分操作的层级：
1. 控制层（Controller）
- 处理用户的请求和响应。
- 负责接收请求参数，调用服务层的方法，将结果返回给客户端。
- 不包含业务逻辑，主要负责调度和协调。
2. 服务层（Service）
- 包含具体的业务逻辑，处理业务规则和流程。
- 调用数据访问层进行数据的读写操作。
- 通常是事务的边界，确保业务操作的一致性和完整性。
- 服务层方法的设计应该是业务相关的，而不是简单的 CRUD 操作。
3. 数据访问层（DAO）
- 负责与数据库进行交互，执行 SQL 操作。
- 提供对数据库的增、删、改、查等基本操作。
- 与具体数据库的交互应该被封装在这一层，以便将来更容易切换数据库。
如何判断操作应该写在哪一层？
- 业务逻辑在哪里？ 如果涉及到业务规则、流程，那么这部分逻辑应该放在服务层。
- 数据操作在哪里？ 如果是与数据库的直接交互，执行增删改查操作，那么应该放在数据访问层。
- 请求和响应在哪里？ 如果是处理 HTTP 请求、处理用户输入、返回结果给用户，那么这部分逻辑应该放在控制层。
- 保持单一职责原则： 每个类或方法应该只负责一种职责。避免在控制层写过多的业务逻辑，也避免在服务层直接操作数据库。
这种划分是一种指导性的原则，具体的架构可能因项目规模、团队习惯等而有所不同。在实际项目中，重要的是保持代码的清晰性、可维护性和可扩展性。
