Django: Breaking up views

Question

This is really just a \"best practices\" question...

I find that When developing an app, I often end up with a lot of views.

Is it common practice to br

Answer 1

Another option would be to move some of the functionality into one or more apps. This would allow you to move also forms and templates and keeping things structurized. You don't necessarily need to move the models which saves you from model and data migration.

For example you could have the following structure:

main_app/
  |_models.py
  |_views.py
  |_forms.py
  |_urls.py
  |_templates/

sub_app_1/
  |_views.py
  |_forms.py
  |_urls.py
  |_templates/

sub_app_2/
  |_views.py
  |_forms.py
  |_urls.py
  |_templates/

Answer 2

Splitting views.py

Most of your code probably expects your views to be accessible as myapp.views.viewname. One way I've seen people break up their views but keep this python name is to create a views/ directory. views/__init__.py will have:

from .foo_views import *
from .bar_views import *
from .baz_views import *

Then, in views/foo_views.py, put:

def foo_detail(request, ...):
    # your code here

def foo_list(request, ...):
    # your code here

def your_other_view(...):
    # ...

etc. So you move everything from views.py into files in this directory, make __init__.py, delete views.py, and you're done.

Then, when you import myapp.views, myapp.views.foo_detail will refer to the function that you defined in views/foo_views.py.

Splitting other modules

This strategy should also work fine for admin.py, etc. But if you want to split up models.py like this, you will need to add app_label = 'your_app_name' to the class Meta: of all of your models. For example, unicorn_app/models/unicorns.py could have an entry like this:

class Unicorn(models.Model):
    description = models.CharField(max_length=80)

    class Meta:
        app_label = 'unicorn_app'

(Otherwise, Django imagines that the Unicorn model is part of a Django app named "models", which messes up the admin site. Current through 1.6 - the upcoming 1.7 release will remove this requirement.)

Answer 3

As a general guideline, think about readability and maintainability: the default "views.py" is just a suggestion made by initial scaffolding - you do not have to stick to it.

Usually, files with thousands of lines of code are difficult to maintain, for this I usually try to decompose bigger modules into smaller ones.
On the other hand, the division should make sense - splitting related functions into several files, with lots of imports may make maintenance even more difficult.

Finally, you can also think about completely other ways to simplify your application.
Do you see duplicated code? Maybe some functionality could be moved in a completely different application? And so on.