Decoupling Domain classes from Django Model Classes

Question

So I have completed my OO analysis and design of a web application that I am building and am now getting into implementation. Design decisions have been made to implement the system using Python and the web development framework Django.

I want to start implementing some of my domain entity classes which need persistence. It seems that Django would have me implement these as classes that are inherited from the Django models class in order to use the Django ORM for persistence. However, this seems like far too strong coupling between my class entities and the persistence mechanism. What happens if at some stage I want to ditch Django and use another web development framework, or just ditch Django’s ORM for an alternative? Now I have to re-write my domain entity classes from scratch.

So it would be better to implement my domain classes as standalone Python classes, encapsulating all my business logic in these, and then use some mechanism (design pattern such as bridge or adapter or ???) to delegate persistence storage of these domain classes to the Django ORM, for example through a Django model class that has been appropriately set up for this.

Does anyone have suggestion on how to go about doing this? It seems from all I have read that people simply implement their domain classes as classes inherited from the Django model class and have business logic mixed within this class. This does not seem a good idea for down line changes, maintenance, reusability etc.

Answer 1

Well, the way to go with Django is to inherit from Django's base model classes. This is the 'active record' pattern. Your django models will have all CRUD and query methods along with you business logic (if you decide to add it of course). This is seen as an anti-pattern in the java world, but the cool thing about it is that it can speed up development really really fast.

Answer 2

Can you seriously envisage a possibility that you're going to just ditch the Django ORM, but keep everything else? Or that if you ditched Django totally, any of your code is still going to be applicable?

You don't complain that if you ditched Django, you'll have to rewrite all your templates. Of course you will, that's to be expected. So why is it OK for the presentation layer to be bound up with the framework, but not the persistence layer?

This sort of up-front over-analysis to be avoided. Django is a RAD tool, and is best suited to quick, iterative development. For all that, it's capable of building some powerful, long-lived applications, as plenty of large companies will testify. But it's not Java, and it's not "enterprisey", and it doesn't conform particularly well to OO principles. In the Python world, that's seen as a feature, not a bug.