Fat Models – A Django Code Organization Strategy
redbeacon.github.io
Fat Models – A Django Code Organization Strategy
1–10 of 36 posts
Re: Fat Models – A Django Code Organization Strategy
#2[deleted]
Re: Fat Models – A Django Code Organization Strategy
#3Not sure I agree with fat models being a "rarely seen, alternative code organization strategy".
It's a natural state which most django codebases tend towards. There's a natural Views use ModelForms use Models data flow which leads to bloat somewhere in that chain as you add code. Fat models are easiest to test and the natural place to put most things, but eventually massive models get unwieldly and you start putting things into helpers. The core thing the author seems to have conflate util functions that have access to a request and helpers that have no connection to the request/response cycle.
Re: Fat Models – A Django Code Organization Strategy
#4[deleted]
Re: Fat Models – A Django Code Organization Strategy
#5I would stick with no classes being "fat". Breaking up fat classes into many smaller classes leads to code being really easy to understand, test, and develop. I tend to stick with the Single-Responsibility-Principle and classes do not become unmanageable. Some people argue that many small classes leads to complex code, but I have not found that to be true in any case I have come across.
Re: Fat Models – A Django Code Organization Strategy
#6Fat models are slightly better than having that crud in your views, but they're still an antipattern. Models should describe the relationships between entities in your business, not be the junk drawer for stuff that doesn't go anywhere else.
Fat models are already a code smell, but passing the request object to your model should really set off alarm bells. You've now made it extremely messy to use your models outside of a web context, making it impossible to unit test them, and pretty much wiped out the purpose of the controller as an encapsulation layer.
Domain-driven design (DDD) provides a lot of patterns that help to keep from either having model code in your views, or these types of junk drawer models.
Basically, DDD as it applies to MVC webapps is: If it's a complex query of some sort, create a query repository that returns model objects rather than a "fat" static method on the model itself. If it's a business transaction, create logic objects that encapsulate the biz logic, and service objects that applies the logic to the models. The controller serves as the broker between requests, services, and entities. You end up with much more testable and reusable code this way.
Re: Fat Models – A Django Code Organization Strategy
#7Fat models are slightly better than having that crud in your views, but they're still an antipattern. Models should describe the relationships between entities in your business, not be the junk drawer for stuff that doesn't go anywhere else. Fat models are already a code smell, but passing the request object to your model should really set off alarm bells. You've now made it extremely messy to use your models outside…
The article precisely says you should not pass the request to the models.
Re: Fat Models – A Django Code Organization Strategy
#8I would stick with no classes being "fat". Breaking up fat classes into many smaller classes leads to code being really easy to understand, test, and develop. I tend to stick with the Single-Responsibility-Principle and classes do not become unmanageable. Some people argue that many small classes leads to complex code, but I have not found that to be true in any case I have come across.
Ah, but there be monsters in that sea too. I used to subscribe to the many-focused-models camp, but depending on the relationships you're trying to model, that can become damn-near unmaintainable as well.
I've actually begun building out more "wide" models, that is, models with a great many fields set to allow null/blank, because mixins and abstract base classes are very hard to maintain 3-4 years out. Don't misunderstand me, there's a place for those, but it's easy to get lost on road to abstraction.
Of course, the lesson is that if you're representing complex relationships in code, the implementation is going to wind up complex to some extent.
Re: Fat Models – A Django Code Organization Strategy
#9I would stick with no classes being "fat". Breaking up fat classes into many smaller classes leads to code being really easy to understand, test, and develop. I tend to stick with the Single-Responsibility-Principle and classes do not become unmanageable. Some people argue that many small classes leads to complex code, but I have not found that to be true in any case I have come across.
"Fat" in this case just means they contain business logic. Many people use their ORM models _exclusively_ as a data layer with no business logic living in the object at all.
Re: Fat Models – A Django Code Organization Strategy
#10Is this article pointing out the most common way of organizing code in Django as an advice?
I'm such a failure at marketing ... sigh