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

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

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

从django模型中分离出数据访问是否真的有价值，或者django是否已经为其ORM提供了足够的数据访问层？

我正在寻找已经实现了相当数量的django应用程序的开发人员，并了解他们的意见。这是一款中小型的网络应用程序。

经过三年的发展，我学到了以下几点。

ORM是访问层。不需要更多。

50%的业务逻辑在模型中。其中一些在形式上被重复或放大。

20%的业务逻辑是以形式进行的。例如，所有数据验证都在表单中。在某些情况下，表单会将通用域(模型中允许)缩小到特定于问题、业务或行业的某些子集。

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

10%的业务逻辑使用管理命令界面在命令行应用程序中结束。这是文件加载、提取和随机批量更改。

查看功能和RESTful Web服务几乎不做任何事情，这一点非常重要。他们尽可能使用模型、表单和其他模块。视图函数和RESTfulWeb服务仅限于处理HTTP和各种数据格式(JSON、HTML、XML、YAML等)的变幻莫测之处。

尝试发明另一个访问层是一个零价值的实践。

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

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

只有当开发人员希望完全分离数据访问层和业务逻辑时，才需要分离数据访问和模型。您可以使用数据映射器设计模式来完成这项工作。一些窗体支持这种设计模式，如SQLAlchemy。pro更灵活，con更复杂。

我推荐MartinFowler写的《企业应用程序体系结构模式》一书来了解更多细节。