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.
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.
- Should south migration files be added to source control?
- How to render a Django form with RadioSelect without getting a checked radiobutton by default?
You would not have to “rewrite your models from scratch” if you wanted a different persistence mechanism. The whole point of an activerecord-style persistence system is that it imposes minimal constraints on the model classes, and acts largely transparently.
If you’re really worried, abstract out any code that relies on queries into their own methods.
- Yuglify compressor can't find binary from package installed through npm
- Django datetime field – convert to timezone in view
I think that there’s no implemented solution for decoupling Django models and the domain classes, at least I haven’t found any. In fact, the only ORM with such decoupling that I know exists only in Smalltalk world and it’s called GLORP. It allows you to persist your domain model in a relational DB without having to modify domain classes. I’m currently trying to implement similar ideas to decouple from Django ORM. My motivation is that current strong coupling between DB tables and domain classes hurts software evolution badly. I’ll post again if I succeed 🙂
- How to limit number of records in Django Rest Framework reverse relations
- Django ALLOWED_HOSTS for Amazon ELB