How to make my Django project more manageable

Question

Coming from classic ASP we are now developing a relatively large Django application. We are trying to figure out how to separate the code for this project into manageable parts.

For the sake of argument let's say that we have CLIENTS, who have a many-to-many relation with USERS, these users have one ROLE, and each role has a many to-many relation to RIGHTS.
Currently, we have all of these in one app, called "backoffice".

The downside is that our forms.py and views.py within the backoffice app, contain classes for all of these entities. Because the application will certainly grow, we would like to separate the code for these entities into several files. So, even though they are not really separate apps (I think), they are certainly dealing with different parts of the backoffice part of our project.

I have read up on the Internet and there seem to be two sentiments; One is to split models.py and views.py etc., and make them into folders/modules. In those folders we could have a clients.py/users.py/roles.py etc. This would keep the app intact, but separate the code. In the end, we would have one big app, with a lot of files.

The other option is to split the code and turn clients, users and roles into seperate apps and remove the "backoffice" app we have now altogether. Django encourages division into smaller apps, but these aren't separate apps really, clients users and roles are closely related and the maintenance tools we are creating reflect this.

I actually started out by creating smaller (sub-)apps within teh "backoffice" app, but I found here that that's a no-go.

The thing is, apps should encourage re-use and the large web-app we are building has al lot of parts interwined and depending on eachother. There is no real way to separate it into smaller re-useable parts that would make real-world sense.

So the question really is; what would be the advisable way to separate the code for users/clients/roles in this example and what are upsides/downsides for either method? Maybe there's even a different method entirely which we haven't found...

Thanks for your time.

Answer 1

Always use separate apps. Subdividing models.py and such is a hack, and works as well as you'd expect a hack to. You're going to spend an inordinate amount of time just fixing the wiring.

The chief positive of small, self-contained apps, though is re-usability. You actually don't even have to make them a part of your project. In fact, I would suggest you don't. Instead, you can package each piece individually, and install them like any other third-party app and just reference them in INSTALLED_APPS. That way, your project focuses only on what's unique to your project, and you can later drop them in to other projects. This also has the side benefit of forcing you to write self-contained code and reduce dependencies on the individual pieces and your project.

FWIW, though, most of the functionality you describe is already baked into Django in it's auth contrib package. What's not already baked in, is already available as third-party packages, so you're really just spinning your wheels here anyways.

Answer 2

I would think about separating each one into its own application. The app structure can be misleading. Although there are many reuasable/plugable django apps, many projects are not trying to repackage each of their apps for reuse. Apps just provide a nice separation of code.

I would image a Role has a model. Might have role specific utility functions and if it were outward facing would probably have roll specific urls.

These could be basic crud operations.

/roles/add, /roles/delete /roles/create, /roles/update/ Each of these could warrant their very own app and urls.py. If clients have the same operations then then they really shouldn't be located in the same view.

THis COULD be solved with multiple views in the same app, but I don't think that is appropriately utilizing the app structure.