后端分层架构：业务逻辑与非业务逻辑的清晰界限
后端开发中，常见的controller、service和dao三层架构并非总是足够清晰。本文探讨如何在service和dao层，甚至引入manager层后，有效区分业务逻辑与非业务逻辑，从而构建更合理的分层设计。
业务逻辑与非业务逻辑的界定
业务逻辑直接关联业务需求，而非业务逻辑则负责底层操作，例如数据访问、数据校验等。两者界限模糊常常导致代码混乱。
-
数据操作的封装: 例如，UserManager.delete() 和 DepartmentManager.delete() 可能同时处理 UserDeptModel 的关联删除。这属于非业务逻辑，因为它关注数据一致性而非业务流程本身。 代码示例：
class UserManager: def delete(self, user_id): self.user_dao.delete(user_id) self.user_dept_dao.delete_by_user_id(user_id) class DepartmentManager: def delete(self, dept_id): self.dept_dao.delete(dept_id) self.user_dept_dao.delete_by_dept_id(dept_id)
-
数据安全处理: 密码加盐等操作通常在dao或manager层执行，因为这是数据保护机制，而非业务逻辑。 代码示例 (python with hypothetical salt function):
class UserDao: def save(self, user): user.password = self.salt(user.password) # ... save user to database ... def salt(self, password): # ... password salting logic ... return salted_password
-
DAO层方法命名规范: DAO层方法名应避免包含业务含义。例如，get_super_user() 不如 get_user_by_type(“super”) 清晰。
-
外部服务调用封装: 如果后端依赖外部服务，应在DAO层封装这些调用，而非service层，因为这属于数据访问，而非业务逻辑。
模拟django Filter功能
在Python中，如果没有依赖注入框架，模拟Django filter需要在DAO层处理请求参数，并逐层传递。 Java的spring框架则简化了这一过程。
数据实体与分层关系
Controller、service和dao并非一一对应。其职责如下：
- Controller: 系统入口，接收和处理请求，保持轻量级。
- Service: 核心业务逻辑处理层，相对复杂。
- DAO: 数据访问层，只负责数据交互，不包含业务逻辑。
例如，“创建用户”业务：Service层执行“检查用户名是否重复”和“创建用户”；DAO层提供“根据用户名查询用户”和“保存用户”方法。
通过清晰区分业务逻辑和非业务逻辑，并遵循合理的分层设计，可以提高代码的可维护性和可扩展性。
