Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fat Models – A Django Code Organization Strategy

redbeacon.github.io

Post reply on HN
Print view View original

11–20 of 36 posts

Re: Fat Models – A Django Code Organization Strategy

#11

Post by jscn »

HeyImAlex wrote: post #9
lgunsch wrote: post #5

I 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.

Which, if you're following the SRP, is the right thing to do, no?

Re: Fat Models – A Django Code Organization Strategy

#12

Post by jscn »

salsakran wrote: post #3

Not 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…

In my experience, fat models are the most common approach to organising code in Django projects. As another comment stated, it's better than having fat views, but it's not ideal.

Re: Fat Models – A Django Code Organization Strategy

#13

Post by unoti »

I write my code as if there will be multiple user interfaces. Usually there are not multiple user interfaces, but thinking as if there will be has a positive impact on the code. Thinking as if there will be multiple user interfaces means putting as little code as possible into the views, since there will be more than one. Some of those user interfaces might not even have Django views and templates, such as a service exposed via Zero MQ. This naturally leads me to putting as much logic as I can either into the models, or sometimes into other modules which in turn use the models. About the only code that goes into views then is the glue that looks things up and gets things ready to be passed into a model.

Re: Fat Models – A Django Code Organization Strategy

#14

Post by Demiurge »

"Fat" abstract models is the way to go if you have logic that operates on the data. It's not even fat. There were fields assigned values in the example. That is exactly what model methods should do.

"Fat" abstract forms is the way to go if your forms have crispy layouts, placeholder initializers, or other stuff that that directly has to do with forms.

Views can be easily split into categorical files and shouldn't contain much logic other than bringing models and presentation together.

Sounds like thinking about what you're doing is the way to go to not have code get out of hand.

Re: Fat Models – A Django Code Organization Strategy

#15

Post by karmajunkie »

gasull wrote: post #7
caseydurfee wrote: post #6

Fat 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.

That doesn't make it any less of an antipattern. The "fat model" pattern is essentially "if you can't figure out where it goes, put it in the model." In the article's example, the credit card processing code is wrapped up into the quote model. I can't think of a single situation in which this is a good idea.

Re: Fat Models – A Django Code Organization Strategy

#16

Post by edwinnathaniel »

I can only shake my head in disbelief when I heard Rails or Django developers touting their framework and saw their actual codebase (ever see FatCRM codebase back in the days? it has been improved significantly these days, but it used to be ... hard to read).

I even shake my head faster when I read the split in opinions in Rails world: the Rails DHH and the DCI/Service Rails.

Moreover, I keep shaking my head when the Django and Rails community voiced their complain over their so-called bloated framework just because they want an API service.

Last but not least, I shake my head again whenever I heard that Django and Rails is not like NodeJS.

C'mon guys... you guys speak a lot of bad things about JAVA yet you've become Java Enterprise Edition.

I suppose JavaEE (especially 6 and 7) does work better in terms of writing maintainable code.

Stuff like Service pattern, Repository pattern, Data mapping pattern, DTO, Value Objects, Mocking are pretty much "common" in most Java projects I've seen or worked on.

I felt that no matter how cool Rails and Django are, when it comes to medium-to-large codebase, Rails/Django are definitely either following the patterns that pretty much common in JavaEE or may not be so comfortable to use anymore.

Re: Fat Models – A Django Code Organization Strategy

#17

Post by edwinnathaniel »

gasull wrote: post #7
caseydurfee wrote: post #6

Fat 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.

But the article passes other unrelated things to the models.

Re: Fat Models – A Django Code Organization Strategy

#18

Post by ollysb »

karmajunkie wrote: post #15
gasull wrote: post #7

Earlier quoted context omitted.

The article precisely says you should not pass the request to the models.

That doesn't make it any less of an antipattern. The "fat model" pattern is essentially "if you can't figure out where it goes, put it in the model." In the article's example, the credit card processing code is wrapped up into the quote model. I can't think of a single situation in which this is a good idea.

The "fat model" pattern is simply organising your logic and relationships into the model layer. How well you organise it is up to you. If you just dump things from the controllers into random parts of the model then that's your choice but there are plenty of ways to design it well.

Re: Fat Models – A Django Code Organization Strategy

#19

Post by edwinnathaniel »

jscn wrote: post #11
HeyImAlex wrote: post #9

Earlier quoted context omitted.

"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.

Which, if you're following the SRP, is the right thing to do, no?

It depends, is it anemic model? or ActiveRecord like model?

Re: Fat Models – A Django Code Organization Strategy

#20

Post by Daishiman »

I honestly think this guy doesn't get it.

The proper way to separate concerns in Django is through applications, which have their own URL routes, models, and views (although they can invoke any other thing in another app).

Through Class-based views you can define base views for common behavior for templates and basic logic, and the built-in views are usually good enough to contain most patterns and easy enough to customize for any other use case you might think of.

A good rule of thumb is that an application should generally have less than a dozen views (I'd say 5 or 6 is enough already). Since each app has its own forms and models file, adding utility methods in an extra file contained within an app is reasonable.

I've used this to manage Django apps with over 50.000 lines of custome code (not counting several dozen extra apps and admin sites with their own customization) and it has never been a problem.

Fat models are just a massive problem. If Python supported extension methods then perhaps you could load your own extensions when performing an action, but a proper design of forms and views that aims for maximum simplity has never failed me.

Post reply on HN