3đ
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.
3đ
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?
0đ
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
0đ
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