后端分层架构如何分离业务与非业务逻辑?
探讨后端开发中的分层架构问题在后端开发中,常见的分层架构包括controller、service和dao...

后端分层架构:巧妙划分业务逻辑与非业务逻辑
后端开发中,分层架构(例如,Controller、Service、DAO三层)至关重要。虽然分层原则清晰,但在实践中,特别是Service层和DAO层间的界限,以及引入Manager层后的逻辑划分,常常令人困惑。本文将探讨如何有效区分业务逻辑和非业务逻辑。
业务逻辑与非业务逻辑的界定
业务逻辑直接关联业务需求,用户可感知;而非业务逻辑则为底层操作,与业务流程无关,例如数据库操作细节或密码加密。
以下是一些非业务逻辑示例:
-
数据库操作细节:
UserManager.delete()和DepartmentManager.delete()可能同时删除关联表(例如userdeptmodel)中的数据。这属于非业务逻辑,因为它只涉及数据库操作,而非业务流程本身。如果没有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) # 假设salt函数用于密码加盐 def save(self): passwd = self.make_password(passwd) self.passwd = passwd super().save() #假设super().save()是数据库保存方法 -
DAO层方法命名:
get_super_user这样的方法名是否合适,取决于其是否涉及业务逻辑。如果super与业务无关,则可以使用;否则,应在Service层处理。 -
HTTP请求封装: 后端依赖的封装,可以放在DAO层,而非Service层。
Python中实现类似Django filter的功能
在Django/Flask中,数据过滤相对容易。但在Python的三层架构中,需要考虑如何在DAO层处理请求参数。如果没有Spring之类的依赖注入框架,则需手动传递参数。 Java中,Hibernate等ORM框架提供了强大的数据过滤和查询功能。
数据实体与分层架构
数据实体用于数据持久化。在三层架构中,Controller、Service和DAO层并非严格一一对应。Service层可能调用多个DAO完成一个业务操作,而一个DAO也可能被多个Service调用。
总之,正确区分业务逻辑和非业务逻辑是后端开发的关键,合理的分层架构能提升代码可读性和可维护性。
Windows 10 是一款微软推出的经典操作系统,拥有硬件兼容性与多任务处理能力。它更偏向把系统状态查看和常用调节动作放在一起,适合需要持续观察和微调设备状态的场景。
极度公式是一款跨平台专业LaTeX公式识别编辑软件,支持OCR公式识别和多平台编辑。和使用说明,避免使用,享受完整功能与稳定支持。做扫描整理、文字提取和表格转换时,它能把识别后的处理步骤接得更顺,资料录入这类场景会省下不少时间。
















