Can I have a main models file in a django project?
Question:
The Problem
I’m working on a django project in which I need to share the same database models over multiple apps, for example when a user opens a page the page is displayed depending on user settings, which can be changed by the user in a different app than the one which displayes the page
At the moment I’ve made the browser app which contains most of my models (because it’s the one I started with) and I’ve got other apps like watch_file and user_settings which then import
This is working but I’m noticing that I’m running into organization problems where I’m hopping from file to file to check models and I’m importing all over the place…
My potential Solution
I was thinking about making one big model file somewhere and just importing the models I need for every app in it’s own model file, however, I read this question in which someone in the comments stated that generally this is not done
Also I red this question which said that sharing models between apps isn’t a good idea at all in regards to organization
The question
In regards to it not being a good idea to make a general model file for all models my project is using, How would I go about organizing it so I don’t have to import so many models from different files for an app to work?
Could I create a something like a helper app which isn’t displayed but is only used to help other apps by having all models in it’s models.py file and importing it frome here in other apps?
Answers:
NB : when talking about “apps” in the following, I mean “project-specific apps”, not “reusable apps”.
It’s perfectly legal (technically) and hardly avoidable in any non-trivial project to have inter-packages dependencies (Django “apps” are first and foremost python packages), so having one app importing models from another app is definitly not a problem in and by itself. Where it becomes a problem is when you start having circular dependencies (A depends on B which depends on C which depends on A…)
A pattern that usually works fine is to have a “core” app on which all other apps can depend but that must not depends on any other app (except contribs app or third-part apps of course), and a “main” app that can depend on any app but that no other app is allowed to depend on. The core app provides the “foundations” for your project – the basic building blocks that all the project will need – and the main app (which usually has no models at all) is responsible for “top-level integration” of everthing (IOW it’s where you put everything that doesn’t clearly belongs to another app and “bridges” the other apps features together).
Then you try to keep other apps mostly self-contained except for dependencies on contribs apps, third-part apps and the core app.
Also note that an app does not necessarily have models AND views AND templates AND templatetags etc etc – you can have simple apps defining a couple models or utils, a “frontend” app (somehow similar to the “main” app in concept actually) that’s responsible for all your project’s views, an “api” app providing a REST api over your other apps models, etc etc.
The Problem
I’m working on a django project in which I need to share the same database models over multiple apps, for example when a user opens a page the page is displayed depending on user settings, which can be changed by the user in a different app than the one which displayes the page
At the moment I’ve made the browser app which contains most of my models (because it’s the one I started with) and I’ve got other apps like watch_file and user_settings which then import
This is working but I’m noticing that I’m running into organization problems where I’m hopping from file to file to check models and I’m importing all over the place…
My potential Solution
I was thinking about making one big model file somewhere and just importing the models I need for every app in it’s own model file, however, I read this question in which someone in the comments stated that generally this is not done
Also I red this question which said that sharing models between apps isn’t a good idea at all in regards to organization
The question
In regards to it not being a good idea to make a general model file for all models my project is using, How would I go about organizing it so I don’t have to import so many models from different files for an app to work?
Could I create a something like a helper app which isn’t displayed but is only used to help other apps by having all models in it’s models.py file and importing it frome here in other apps?
NB : when talking about “apps” in the following, I mean “project-specific apps”, not “reusable apps”.
It’s perfectly legal (technically) and hardly avoidable in any non-trivial project to have inter-packages dependencies (Django “apps” are first and foremost python packages), so having one app importing models from another app is definitly not a problem in and by itself. Where it becomes a problem is when you start having circular dependencies (A depends on B which depends on C which depends on A…)
A pattern that usually works fine is to have a “core” app on which all other apps can depend but that must not depends on any other app (except contribs app or third-part apps of course), and a “main” app that can depend on any app but that no other app is allowed to depend on. The core app provides the “foundations” for your project – the basic building blocks that all the project will need – and the main app (which usually has no models at all) is responsible for “top-level integration” of everthing (IOW it’s where you put everything that doesn’t clearly belongs to another app and “bridges” the other apps features together).
Then you try to keep other apps mostly self-contained except for dependencies on contribs apps, third-part apps and the core app.
Also note that an app does not necessarily have models AND views AND templates AND templatetags etc etc – you can have simple apps defining a couple models or utils, a “frontend” app (somehow similar to the “main” app in concept actually) that’s responsible for all your project’s views, an “api” app providing a REST api over your other apps models, etc etc.