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

31–36 of 36 posts

Re: Fat Models – A Django Code Organization Strategy

#31

Post by jhh »

mrfusion wrote: post #27

Maybe you guys can help me apply this to an actual Django project I'm working on. So I made an "Order" model to track orders. But now I have to add a lot of logic regarding things such as what can be ordered together, and which users can order what. Where you keep that logic? It seems to make sense to me to put it right in the model, no?

Personally I would make models a package rather than just a module (since you sy you have a lot of order related logic). I would create one or more modules in this package, presumably one of those for orders.

Then I would actually create the base logic which clearly belongs to one Order instance as methods on the Order class.

If you have something like "can x and y and (...)" be ordered together I would make an unbound function in your orders module which takes an iterable (Lists etc.) of Orders and works on it.

Note that I am by no means a Django guru or something like that.

Re: Fat Models – A Django Code Organization Strategy

#32

Post by collyw »

singingfish wrote: post #22
ollysb wrote: post #18

Earlier quoted context omitted.

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.

I'm closely involved in a big system that uses Catalyst (perl's nearest equivalent to Django). We spend allmost all of our time in Model classes (MyDomain::Model::Whatever, not MyWebApp::Model::Whatever that's just a dumb connector). It works well and I get the shits every time I have to deal with code that doesn't separate this stuff out properly. Also works on the front end using modern javascript.

I have most of my logic in the views (because I didn't now any better when starting my project). I know the Django way suggests fat models (well I know that now). But is it honestly that big of a deal? I know in my app that any complex logic will be in the views. What will I gain by following these best practices?

Re: Fat Models – A Django Code Organization Strategy

#33

Post by rartichoke »

Does anyone else feel weird knowing that when you call that model method it may or may not call out to a background worker task?

Why not just throw all of your celery tasks that are related to an app inside of a worker.py file or something else?

If you import from service.py or worker.py then it becomes obvious the thing you're doing is happening in the background.

Re: Fat Models – A Django Code Organization Strategy

#34

Post by singingfish »

collyw wrote: post #32
singingfish wrote: post #22

Earlier quoted context omitted.

I'm closely involved in a big system that uses Catalyst (perl's nearest equivalent to Django). We spend allmost all of our time in Model classes (MyDomain::Model::Whatever, not MyWebApp::Model::Whatever that's just a dumb connector). It works well and I get the shits every time I have to deal with code that doesn't separate this stuff out properly. Also works on the front end using modern javascript.

I have most of my logic in the views (because I didn't now any better when starting my project). I know the Django way suggests fat models (well I know that now). But is it honestly that big of a deal? I know in my app that any complex logic will be in the views. What will I gain by following these best practices?

Yeah, try having a fat controller or view, on a rapidly developing codebase with poor specs which change mid-project regularly while avoiding getting fired.

Re: Fat Models – A Django Code Organization Strategy

#35

Post by collyw »

singingfish wrote: post #34
collyw wrote: post #32

Earlier quoted context omitted.

I have most of my logic in the views (because I didn't now any better when starting my project). I know the Django way suggests fat models (well I know that now). But is it honestly that big of a deal? I know in my app that any complex logic will be in the views. What will I gain by following these best practices?

Yeah, try having a fat controller or view, on a rapidly developing codebase with poor specs which change mid-project regularly while avoiding getting fired.

Sounds very like my work.

Yeah, schema changes are a pain in the arse, but I don't see that moving my code from views to models would have a great deal of impact (though I am gradually moving the code that way when it does need changed).

Re: Fat Models – A Django Code Organization Strategy

#36

Post by singingfish »

collyw wrote: post #35
singingfish wrote: post #34

Earlier quoted context omitted.

Yeah, try having a fat controller or view, on a rapidly developing codebase with poor specs which change mid-project regularly while avoiding getting fired.

Sounds very like my work. Yeah, schema changes are a pain in the arse, but I don't see that moving my code from views to models would have a great deal of impact (though I am gradually moving the code that way when it does need changed).

A better answer is, that you get to decouple the functionality of your application's business logic from the web portion. This is achieved trivially purely by applying disciplined coding standards. Removing the web dependency makes the code much much easier to write automated tests for, and it gives a sane development path when making minor or major changes to feature sets.
Post reply on HN