django models = business logic + data access? Or data access layer should be separated out from django model?

Question

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.

Velum

The data access layer is the ORM. It is separate from the model. You're not going to change ORM's. You are going to change database engines; and that's already made trivial by the ORM layer. It's not clear what your colleagues mean by "data access layer". Can you provide more information? – Dosser

possible duplicate of Separation of business logic and data access in django – Waugh

@the_drow: OT: can you please stop robo-reviewing and pay attention to edits? This suggested edit was an obvious comment, not a suggested edit that should have been accepted. – Perron

@MartijnPieters: I'm used to these style of edits. If the culture at SO has changed I was not aware of it. – Waugh

@the_drow: See the meta discussion the suggested edit sparked. At the very least the edit should have been improved; the 'hope it helps' and 'edit' headers are not helpful. I feel that that edit should have been a comment instead, unless you understand the subject matter in detail and agree that the edit was correct from a technical point of view. – Perron

Answer 1

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.

Dosser

some excellent details about a more explicit architecture for django: #12579408 – Velum

I disagree that the ORM is the data access layer; the ORM comprises most of the data access layer. Using an ORM directly in your models and associating database tables with model attributes couples your application to relational databases and to a specific ORM (eg Django). This is inherent to the active record design pattern, which Django uses (docs.djangoproject.com/en/dev/misc/design-philosophies). If you want to uncouple business logic and data access, you should use data mapper design pattern instead (eg SQLAlchemy ORM supports that). That may be overkill for some apps, though. – Canalize

Answer 2

The answer depends on the requirements of your application.

For applications which will always use relational databases and can be coupled with a specific ORM, you do not need to separate data access and models. Django ORM is based on the active record design pattern, which supposes data access and model are together. Pro is simplicity, con is less flexibility.

Separating data access and model is only necessary when developer wants to uncouple completely data access layer and business logic. You can do it with the data mapper design pattern. Some ORMs support this design pattern, such as SQLAlchemy. Pro is more flexibility, con is more complexity.

I recommend the book "Patterns of Enterprise Application Architecture" written by Martin Fowler for more details.

Canalize