django模型=业务逻辑+数据访问？或者数据访问层应该从django模型中分离出来？

本文介绍了django模型=业务逻辑+数据访问？或者数据访问层应该从django模型中分离出来？的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 在Django中，建议的软件架构是将所有的业务逻辑和数据访问都放在模型中。

但是，有些同事建议数据访问层应该与业务逻辑（业务服务层）分开。他们的理由是，如果使用不同的数据源，数据访问层可以隔离更改。他们还说可以有多种模式的业务逻辑。但是，当我开始使用单独的数据访问和业务逻辑层进行编码时，数据访问层很简单（基本上是定义数据库模式的模型代码），而且似乎没有多少价值。

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

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

解决方案

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

ORM是访问层。没有更多的需要。

50％的业务逻辑在模型中。其中一些在表单中重复或放大。

20％的业务逻辑在表单中。例如，所有的数据验证都是以表格形式出现的。在某些情况下，表单将缩小一般域（允许在模型中）到某个特定于问题，业务或行业的子集。

20％的业务逻辑在应用程序中的其他模块中出现。这些模块高于模型和表单，但在视图功能下方，RESTful Web服务和命令行应用程序。

业务逻辑的10％使用管理命令界面的线程应用程序。这是文件加载，提取和随机批量更改。

查看功能和RESTful Web服务几乎没有任何事情非常重要。他们尽可能使用模型，表单和其他模块。视图功能和RESTful Web服务仅限于处理HTTP和各种数据格式（JSON，HTML，XML，YAML，无论如何）的变幻莫测。

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

In Django, the suggested software architecture is to put all business logic and data access in models.

But, some colleagues have suggested that the data access layer should be separate from the business logic (business service layer). Their justification is that the data access layer can isolate changes if a different data source is used. They also say that there is business logic that can be in more than one model.

But, when I start coding using the separate data access and business logic layers, the data access layer is simple (basically the model code that defines the db schema) and it does not seem to add much value.

Is there really value in separating out the data access from django models or does django already provide a sufficient data access layer with its ORM?

I'm looking for developers that have implemented a fair number of django apps and find out what their opinion is. This is for a small to medium sized web app.

解决方案

After three years of Django development, I've learned the following.

The ORM is the access layer. Nothing more is needed.

50% of the business logic goes in the model. Some of this is repeated or amplified in the Forms.

20% of the business logic goes in Forms. All data validation, for example, is in the forms. In some cases, the forms will narrow a general domain (allowed in the model) to some subset that's specific to the problem, the business or the industry.

20% of the business logic winds up in other modules in the application. These modules are above the models and forms, but below the view functions, RESTful web services and command-line apps.

10% of the business logic winds up in command-line apps using the management command interface. This is file loads, extracts, and random bulk changes.

It's very important that view functions and RESTful web services do approximately nothing. They use models, forms, and other modules as much as possible. The view functions and RESTful web services are limited to dealing with the vagaries of HTTP and the various data formats (JSON, HTML, XML, YAML, whatever.)

Trying to invent Yet Another Access Layer is a zero-value exercise.