后端三层架构：业务逻辑与数据访问逻辑的界限
后端开发中，常见的controller、service和dao三层架构，在controller和service层的分离相对清晰，主要通过分离业务逻辑和展示逻辑实现，例如将消息队列(MQ)、HTTP、RPC等与业务逻辑解耦。然而，service层和dao层之间的界限，特别是引入manager层后，常常让开发者感到困惑。
Python后端开发中，业务逻辑有时会混杂在model层中，例如usermodel.is_super()这样的业务查询方法，或usermodel.objects.all()这样的原生数据库操作，甚至usermodel.**这样的跨表操作。
业务逻辑与非业务逻辑的辨析
业务逻辑与非业务逻辑的关键在于是否直接关联客户需求。客户无法感知的逻辑通常视为非业务逻辑，包括：
数据库结构与关联关系: 例如，usermanager.delete()和departmentmanager.delete()方法可以同时处理关联表（如userdeptmodel）的删除，无需在service层分别调用dao层方法两次。 即使没有manager层，dao层也可以进行这类关联或跨表操作，只要这些操作与业务逻辑无关。
class UserManager: def delete(self): userdao.delete() userdeptdao.delete()class DepartmentManager: def delete(self): departmentdao.delete() userdeptdao.delete()
密码加盐: 用户只需要知道密码并非明文存储，加盐操作可以在dao或manager层处理。
class UserDao: def make_password(self, passwd): return salt(passwd) # 加盐函数 def save(self): self.passwd = self.make_password(self.passwd) super().save()
dao层方法命名与定义: dao层方法命名，例如使用get_super_user这样的语义化名称是否合适，取决于其是否与业务逻辑相关。如果super与业务无关，使用get_super_user是可以接受的。
度加剪辑
度加剪辑（原度咔剪辑），百度旗下AI创作工具
63 查看详情
HTTP请求封装: 后端依赖（例如其他团队提供的服务）可以封装成dao层方法，而非service层方法。
Django/Flask中实现类似Django filter的功能
在Django和Flask中实现类似Django filter的功能时，常常遇到层层穿透的问题，因为dao层需要传入请求参数。在没有类似Spring这样的依赖注入框架的情况下，可以考虑：
在Java中，通常使用MyBatis或JPA等框架，通过注解和配置文件管理数据访问和过滤逻辑。
数据实体与三层架构的关系
数据实体表示系统中的数据对象。在三层架构中，controller、service和dao层并非严格一一对应：
dao层可能包含多个方法处理不同的数据实体，例如userdao和departmentdao。service层可能需要组合多个dao层方法来实现完整的业务逻辑。
总而言之，dao层只负责数据存储交互，不包含业务逻辑；service层负责执行业务逻辑。例如，创建用户时，service层检查用户名是否重复，然后调用dao层方法保存用户。 这种架构设计旨在按职责划分系统，提高代码的可维护性和可扩展性。
以上就是后端开发中如何区分业务逻辑与存储逻辑？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/351712.html
微信扫一扫 
支付宝扫一扫 
