我要评论
后端三层架构：业务逻辑与数据访问逻辑的界限
后端开发中，常见的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是可以接受的。
-
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层方法保存用户。 这种架构设计旨在按职责划分系统，提高代码的可维护性和可扩展性。
以上就是后端开发中如何区分业务逻辑与存储逻辑？的详细内容，更多请关注代码网其它相关文章！
![Flask-SQLAlchemy中db.metadatas["auth"]到底是什么？](https://images1.3wcode.com/3wcode/20250329/s_0_202503292219331889.jpg)
发表评论