On Mon, Sep 27, 2010 at 10:07 AM, Mike Dewhirst <mi...@dewhirst.com.au> wrote: > On 27/09/2010 5:08pm, MrMuffin wrote: >> >> Where do you put your business logic in django? In my project I`ve put >> it into the models.py, but that file soon become huge and hard to >> maintain. Of course I can just stuff it into whatever file I like, but >> I`d like to have some standard way of doing this. There seems to be >> something missing in django when it comes to business logic. It`s all >> model, views and templates and that`s all great for small projects, >> but both the models.py and views.py very soon gets huge and how do you >> re-organize your project when that happens? Splitting views and models >> into seperate files is only a partial solution and that requires some >> hackish code in __init__.py to make syncdb etc work. And then there`s >> urls.py. >> >> Should there be a better and standardized way to organize huge >> projects in django? > > I hope some dguru answers this because it is important. > > I reckon business rules should be in models.py because that represents the > database and I've always thought that is where the business rules belong for > the sake of data integrity. > > There is probably nothing wrong with multiple model files named for the > tables in the app if you want to keep them small. You might want to import > them 'from app import table_x.table_x as table_x'. Bit ugly I suppose - this > is really why it makes lotsa sense to split a big project up. > > Business logic is different than business rules. That is simply the > application logic and that probably belongs in views.py but there is nothing > stopping you importing stuff from app_logic.py which can import stuff from > big_project.py. > > If it is a giant project you probably ought to split it into smaller apps > each of which is focused on a self-contained subset of your entire > functionality. That way, you might be able to put parts of it on sourceforge > and I can use it :) > > Mike > >> >> Thanks for your time.
Stuffing logic and huge amounts of code into models.py sounds like a terrible idea. It doesn`t belong in views.py either. In a simple app this works fine, but not for larger projects. There might be at least two different ways to handle this; 1) like one guy points out - it`s up to the developer to choose or 2) try to get the django community/core dev/etc to come up with a more standard way of doing it. I`m probably more in support of the second option. Almost all of my projects start quite small, but outgrown one models.py and one views.py rather quick. And that`s not even thinking of all the business logic, just plain data models and views. So what do I do? Thanks for all your input anyway :-) -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
