django模型=业务逻辑+数据访问？或者应该从django模型中分离出数据访问层？
在Django中，建议的软件架构是将所有业务逻辑和数据访问放在模型中。
但是，一些同事建议将数据访问层与业务逻辑(业务服务层)分开。他们的理由是，如果使用不同的数据源，数据访问层可以隔离更改。他们还说，业务逻辑可以存在于多个模型中。
但是，当我开始使用单独的数据访问层和业务逻辑层进行编码时，数据访问层很简单(基本上是定义db模式的模型代码)，而且它似乎并没有增加多少价值。
将数据访问从django模型中分离出来是否真的有价值，或者django已经为其ORM提供了足够的数据访问层？
我正在寻找已经实现了相当数量的django应用程序的开发人员，并了解他们的意见。这是一个小型到中型的web应用程序。
回答 2
Stack Overflow用户
发布于 2012-01-19 00:33:07
经过三年的Django开发，我学到了以下几点。
ORM是接入层。不需要更多的东西。
50%的业务逻辑放在模型中。其中一些在表单中被重复或放大。
20%的业务逻辑以表单的形式存在。例如，所有数据验证都在表单中。在某些情况下，表单会将一般域(模型中允许的)缩小到特定于问题、业务或行业的某些子集。
20%的业务逻辑在应用程序的其他模块中完成。这些模块位于模型和表单的上方，但位于视图函数、RESTful web服务和命令行应用程序的下方。
10%的业务逻辑在使用管理命令界面的命令行应用程序中完成。这是文件加载、提取和随机批量更改。
视图函数和RESTful web服务几乎什么也不做，这一点非常重要。他们尽可能多地使用模型、表单和其他模块。视图函数和HTTP服务仅限于处理反复无常的RESTful和各种数据格式(等等)。
试图发明另一个接入层是一个零值练习。
Stack Overflow用户
发布于 2014-12-01 21:08:06
答案取决于您的应用程序的需求。
对于将始终使用关系数据库并可以与特定ORM耦合的应用程序，您不需要将数据访问和模型分开。Django ORM基于active record设计模式，该设计模式假设数据访问和模型是一起的。优点是简单性，缺点是灵活性差。
只有当开发人员希望完全解耦数据访问层和业务逻辑时，才需要将数据访问和模型分离。您可以使用数据映射器设计模式来完成此任务。有些ORM支持这种设计模式，比如SQLAlchemy。Pro更灵活，con更复杂。
我推荐Martin Fowler写的“企业应用程序架构的模式”一书，了解更多细节。
https://stackoverflow.com/questions/8913629
复制相似问题
腾讯云开发者
