4

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?

BRHSM
  • 854
  • 3
  • 13
  • 48

1 Answers1

9

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.

bruno desthuilliers
  • 75,974
  • 6
  • 88
  • 118
  • Thanks for the quick response! I think I understand what you mean however I don't get why you need to seperate the main app from the core app? Why not make an app that just handles both the models other apps uses as well as the "bridges" between them? (How I understand it with "bridges" you mean models which simply connect 2 or more other models like an N to M relation in a database right?) – BRHSM Dec 13 '17 at 16:37
  • "I don't get why you need to seperate the main app from the core app" => because the core app is the one that everyone can depends one, while the main app is the one no one is ever allowed to depend on. And "bridging" is not about specifically models and relationships actually. – bruno desthuilliers Dec 13 '17 at 16:50
  • I am developing a complex project. currently i have many apps, each apps is highly dependent on each others' models. so is it okay to have a 'core' app to keep all the models (centralize models) to avoid migrations dependency in the future? example: the app_a/views.py and app_b/views.py will import core.a_model and core. b_model respectively. @brunodesthuilliers – Loonb Apr 02 '19 at 14:55
  • 1
    @TianLoon if "each app is highly dependent on each others' models" then you definitly want to refactor all this into a single app indeed (or perhaps a couple apps depending on your exact dependencies). As a general rule, as soon as two modules or packages depends on each other you want to refactor them either into a single module/package or extract the relevant parts into a third distinct one (depending on what makes sense in the context). – bruno desthuilliers May 09 '19 at 09:26