Django: best practice for splitting up project into apps [closed]

Question

I'm really struggling with this whole app-idea. I read a lot of tutorials and style guides and I know I should try to create specialized apps, that do exactly one thing. This all makes sense when looking at some simple tutorial project but as soon as it gets to a complex real life project, I find myself unable to determine how I should draw the lines between different apps.

One of the problems is, that I want to have one site (or multiple sites) where the user sees a lot of different stuff. Stuff that should be from different apps, when following the app design rules. How would I realize something like this? My first idea was to create one app called ui, that just handles ALL the views the actually lead to a template and all the other apps provide the models and helperfunctions. But I fear that the ui app will become way to big.

To give you a small example: Lets I want to have a site where the user can do the following tasks:

• Select a subject
• set some options to the selected subject
• upload files that are associated with his account
• assign some of the uploaded files to the subject
• record some audio which will be related to the subject

Right now, I would create three apps:

1. subjects (contains the subject model and some related models)
2. resources (contains the resource model, handles uploads)
3. audio (handles all the audio recording and processing stuff)

But then, I would need some kind of main or ui app to handle how these apps interact and to create the actual site, where all the apps are somehow involved.

So, is there any "right" way to do this? Or are there any patterns that I can use? I would also appreciate links to good resources about this topic, even though I already read quite a few.

Rhigolene

Answer 1

You just need to make sure your structure makes sense to you.

There's no requirement to create a new app for every feature that is bound to another part of the project's logic.

Reusable apps are a whole different story, their code should be unaware of the implementation to some extent.

Take a look at Django's structure for inspiration

A possible layout for your example:

project_root/
    project/
        __init__.py
        settings.py
        urls.py
        templates/
            app1/  # override stuff
        static/
        media/
    app1/
        __init__.py
        admin/  # as a package
            __init__.py
            subjects.py
            resources.py
            # etc
        models/  # as a package
            subjects.py
            resources.py
            # etc
        managers/
            __init__.py
            subjects.py
            resources.py
            # etc
        services/
            __init__.py
            audio.py  # upload handler etc
        views/
            __init__.py
            subjects.py
        urls/
            __init__.py
            subjects.py
        templates/
            app1/
                subject_list.html  # override at project level
        static/
            app1/
                css/
                    subject.css  # override at project level
    app2/
        __init__.py
        models.py  # holds a Member model or whatever you require
    manage.py

Laverne

thanks a lot! maybe I was overthinking the whole app-pattern a little. but this makes actually a lot more sense. One question though: how does "overriding at project level" work? Or what do you mean by that? – Rhigolene

@Rhigolene Django's inheritance system will look for a template or css file in your project's level first, then recourse to app level etc (depending on your settings, top to bottom) this is of great use when reusing parts of your code cross projects, where you don't want to use project specific style/template hooks. Mind you, package deep models require import statements in the init file and use of the app_label argument on a model's Meta class. – Laverne

Thanks again! I already restructured some of my code and it's already a lot cleaner for me. – Rhigolene

Answer 2

I think the best way to delimit an app is roughly equivalent to the way you delimit a class on an Objected Oriented Programming Language. Instead of variables and methods, you think of models and views respectively:

models are the state of the object, views are used to see and interact with the state of the object.

My rule of thumb is, does creating an app help to encapsulate a specific set of models? If that is the case, then I try to create it.

Astilbe