后端开发中如何区分业务逻辑与存储逻辑？

后端开发中，常见的controller、service和dao三层架构，在controller和service层的分离相对清晰，主要通过分离业务逻辑和展示逻辑实现，例如将消息队列(MQ)、HTTP、RPC等与业务逻辑解耦。然而，service层和dao层之间的界限，特别是引入manager层后，常常让开发者感到困惑。

Python后端开发中，业务逻辑有时会混杂在model层中，例如usermodel.is_super()这样的业务查询方法，或usermodel.objects.all()这样的原生数据库操作，甚至usermodel.**这样的跨表操作。

业务逻辑与非业务逻辑的关键在于是否直接关联客户需求。客户无法感知的逻辑通常视为非业务逻辑，包括：

1. 数据库结构与关联关系: 例如，usermanager.delete()和departmentmanager.delete()方法可以同时处理关联表（如userdeptmodel）的删除，无需在service层分别调用dao层方法两次。 即使没有manager层，dao层也可以进行这类关联或跨表操作，只要这些操作与业务逻辑无关。

   PHP

   class UserManager:
       def delete(self):
           userdao.delete()
           userdeptdao.delete()
   class DepartmentManager:
       def delete(self):
           departmentdao.delete()
           userdeptdao.delete()

2. 密码加盐: 用户只需要知道密码并非明文存储，加盐操作可以在dao或manager层处理。

   PHP

   class UserDao:
       def make_password(self, passwd):
           return salt(passwd)  # 加盐函数
       def save(self):
           self.passwd = self.make_password(self.passwd)
           super().save()

3. dao层方法命名与定义: dao层方法命名，例如使用get_super_user这样的语义化名称是否合适，取决于其是否与业务逻辑相关。如果super与业务无关，使用get_super_user是可以接受的。

4. HTTP请求封装: 后端依赖（例如其他团队提供的服务）可以封装成dao层方法，而非service层方法。

在Django和Flask中实现类似Django filter的功能时，常常遇到层层穿透的问题，因为dao层需要传入请求参数。在没有类似Spring这样的依赖注入框架的情况下，可以考虑：

• 在Java中，通常使用MyBatis或JPA等框架，通过注解和配置文件管理数据访问和过滤逻辑。

数据实体表示系统中的数据对象。在三层架构中，controller、service和dao层并非严格一一对应：

• dao层可能包含多个方法处理不同的数据实体，例如userdao和departmentdao。
• service层可能需要组合多个dao层方法来实现完整的业务逻辑。

总而言之，dao层只负责数据存储交互，不包含业务逻辑；service层负责执行业务逻辑。例如，创建用户时，service层检查用户名是否重复，然后调用dao层方法保存用户。 这种架构设计旨在按职责划分系统，提高代码的可维护性和可扩展性。

以上就是后端开发中如何区分业务逻辑与存储逻辑？的详细内容，更多请关注知识资源分享宝库其它相关文章！