Is it a good programming practice to separate models from the rest of the application

Question

My project consists of several django applications that need to be deployed in different ways, possibly on different machines. However, often these applications sometimes need access to other models, so I thought about “externalizing” my models so that they can be obtained more elegantly from any application. Therefore, the idea is to have a directory structure similar to something like this:

/ + application1 + application2 + models 

Is there a functional point for this (other than code support), since applications can cross-reference each other?

Answer 1

The following paragraph in the django book makes me think that this is probably not a good idea (I added bold formatting):

However, there is one requirement for an application agreement: if you are using the Djangos database layer (s), you must create a Django application. Models must live in applications . Thus, to start writing our models, you need to create a new application.

Answer 2

The following comments did not match the comments of @jcollado, so I will put them here:

https://docs.djangoproject.com/en/dev/topics/db/models/#models-across-files

Models with files

It’s all right to associate the model with one from another application. To do this, import the linked model at the top of the model containing your model. Then simply refer to another class of model where necessary. For instance:

 from geography.models import ZipCode class Restaurant(models.Model): # ... zip_code = models.ForeignKey(ZipCode) 

Answer 3

I do not think this is a particularly good idea, although I see an appeal. You will include many models that you do not use if you want to install only one of the applications you have installed. I think it’s best to keep the models in the application to which they relate.

It can also make using the admin interface more confusing. Where do you register models with admin? Where do you configure the administrator for the model?