Django模型 = 业务逻辑 + 数据访问？还是说数据访问层应该从Django模型中分离出来？

Question

Django建议的软件架构是将所有业务逻辑和数据访问都放在模型中。

但是，一些同事建议将数据访问层与业务逻辑（业务服务层）分开。他们的理由是，数据访问层可以隔离更改，如果使用不同的数据源。他们还说，在一个以上的模型中可能存在业务逻辑。

但是，当我开始使用单独的数据访问和业务逻辑层编码时，数据访问层很简单（基本上是定义数据库模式的模型代码），似乎没有增加多少价值。

将数据访问从Django模型中分离出来真的有价值吗？还是Django已经通过其ORM提供了足够的数据访问层？

我正在寻找那些实现了相当数量的Django应用程序并了解他们意见的开发人员。这是针对一个中小型Web应用程序的。

- TaiwanGrapefruitTea

---

数据访问层是ORM。它与模型是分开的。你不会更改ORM。你将更改数据库引擎；并且ORM层已经使其变得微不足道。不清楚你的同事所说的“数据访问层”的含义。你能提供更多信息吗？ - S.Lott

可能是在Django中分离业务逻辑和数据访问的重复问题。 - the_drow

@the_drow：OT：你能停止机器审核并注意编辑吗？这个建议的编辑明显是一条评论，而不是应该被接受的建议编辑。 - Martijn Pieters

@MartijnPieters：我已经习惯了这种编辑风格。如果SO的文化发生了变化，我并不知情。 - the_drow

@the_drow：请查看元讨论，这个建议编辑引发了一些反应。至少，这个编辑应该被改进；“希望有所帮助”和“编辑”标题并不是很有用。我认为，除非你详细了解主题并同意从技术角度上看这次编辑是正确的，否则这个编辑应该是一条评论而不是一个编辑。 - Martijn Pieters

Answer 1

经过三年的Django开发，我学到了以下经验。

ORM是访问层，不需要其他的东西。

50%的业务逻辑在模型中实现。其中部分逻辑会在表格中重复或放大。

20%的业务逻辑在表格中实现，例如所有数据验证都在表格中。有时，表格将把一个通用领域（在模型中允许）缩小到某个特定于问题、业务或行业的子集中。

20%的业务逻辑最终会出现在应用程序的其他模块中。这些模块位于模型和表单之上，但位于视图函数、RESTful web服务和命令行应用程序之下。

10%的业务逻辑最终以管理命令接口使用命令行应用程序实现。这包括文件加载、提取和随机批量更改。

视图函数和RESTful web服务几乎什么都不做非常重要。它们尽可能多地使用模型、表单和其他模块。视图函数和RESTful web服务仅限于处理HTTP和各种数据格式（JSON、HTML、XML、YAML等）的各种状况。

试图发明另一种访问层是一种毫无价值的练习。

- S.Lott

---

有关 Django 更明确的架构的一些出色细节：https://dev59.com/ymcs5IYBdhLWcg3wym4h?rq=1 - TaiwanGrapefruitTea

我不同意ORM就是数据访问层，ORM包含了大部分的数据访问层。直接在模型中使用ORM，并将数据库表与模型属性关联，会将您的应用程序与关系数据库和特定的ORM（例如Django）耦合起来。这是活动记录设计模式固有的问题，Django使用了该模式(https://docs.djangoproject.com/en/dev/misc/design-philosophies/)。如果您想要解耦业务逻辑和数据访问，您应该使用数据映射器设计模式(例如SQLAlchemy ORM支持该模式)。但是，对于某些应用程序来说，这可能过于复杂。 - Alan Evangelista

Answer 2

答案取决于您的应用程序要求。

对于始终使用关系型数据库并可以与特定ORM耦合的应用程序，您不需要分离数据访问和模型。Django ORM基于活动记录设计模式，假设数据访问和模型在一起。优点是简单，缺点是灵活性较差。

只有当开发人员想要完全解除数据访问层和业务逻辑的耦合时，才需要分离数据访问和模型。您可以使用数据映射器设计模式来完成此操作。一些ORM支持此设计模式，例如SQLAlchemy。优点是更灵活，缺点是更复杂。

我建议阅读Martin Fowler所著的《企业应用架构模式》以获取更多详细信息。

- Alan Evangelista