后端开发中如何区分业务逻辑和非业务逻辑，并合理进行分层设计？

后端分层架构：业务逻辑与非业务逻辑的清晰界限

后端开发中，常见的controller、service和dao三层架构并非总是足够清晰。本文探讨如何在service和dao层，甚至引入manager层后，有效区分业务逻辑与非业务逻辑，从而构建更合理的分层设计。

业务逻辑与非业务逻辑的界定

业务逻辑直接关联业务需求，而非业务逻辑则负责底层操作，例如数据访问、数据校验等。两者界限模糊常常导致代码混乱。

1. 数据操作的封装: 例如，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)

   登录后复制

2. 数据安全处理: 密码加盐等操作通常在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

   登录后复制

3. DAO层方法命名规范: DAO层方法名应避免包含业务含义。例如，get_super_user() 不如 get_user_by_type("super") 清晰。

4. 外部服务调用封装: 如果后端依赖外部服务，应在DAO层封装这些调用，而非service层，因为这属于数据访问，而非业务逻辑。

模拟Django filter功能

在Python中，如果没有依赖注入框架，模拟Django filter需要在DAO层处理请求参数，并逐层传递。 Java的Spring框架则简化了这一过程。

数据实体与分层关系

Controller、service和dao并非一一对应。其职责如下：

1. Controller: 系统入口，接收和处理请求，保持轻量级。
2. Service: 核心业务逻辑处理层，相对复杂。
3. DAO: 数据访问层，只负责数据交互，不包含业务逻辑。

例如，“创建用户”业务：Service层执行“检查用户名是否重复”和“创建用户”；DAO层提供“根据用户名查询用户”和“保存用户”方法。

通过清晰区分业务逻辑和非业务逻辑，并遵循合理的分层设计，可以提高代码的可维护性和可扩展性。

以上就是后端开发中如何区分业务逻辑和非业务逻辑，并合理进行分层设计？的详细内容，更多请关注php中文网其它相关文章！