models.py getting huge, what is the best way to break it up?
Question:
Directions from my supervisor:
“I want to avoid putting any logic in the models.py. From here on out, let’s use that as only classes for accessing the database, and keep all logic in external classes that use the models classes, or wrap them.”
I feel like this is the wrong way to go. I feel that keeping logic out of the models just to keep the file small is a bad idea. If the logic is best in the model, that’s where it really should go regardless of file size.
So is there a simple way to just use includes? In PHP-speak, I’d like to propose to the supervisor that we just have models.py include() the model classes from other places. Conceptually, this would allow the models to have all the logic we want, yet keep file size down via increasing the number of files (which leads to less revision control problems like conflicts, etc.).
So, is there a simple way to remove model classes from the models.py file, but still have the models work with all of the Django tools? Or, is there a completely different yet elegant solution to the general problem of a “large” models.py file? Any input would be appreciated.
Answers:
Django is designed to let you build many small applications instead of one big application.
Inside every large application are many small applications struggling to be free.
If your models.py feels big, you’re doing too much. Stop. Relax. Decompose.
Find smaller, potentially reusable small application components, or pieces. You don’t have to actually reuse them. Just think about them as potentially reusable.
Consider your upgrade paths and decompose applications that you might want to replace some day. You don’t have to actually replace them, but you can consider them as a stand-alone “module” of programming that might get replaced with something cooler in the future.
We have about a dozen applications, each model.py is no more than about 400 lines of code. They’re all pretty focused on less than about half-dozen discrete class definitions. (These aren’t hard limits, they’re observations about our code.)
We decompose early and often.
It’s natural for model classes to contain methods to operate on the model. If I have a Book model, with a method book.get_noun_count(), that’s where it belongs–I don’t want to have to write “get_noun_count(book)“, unless the method actually intrinsically belongs with some other package. (It might–for example, if I have a package for accessing Amazon’s API with “get_amazon_product_id(book)“.)
I cringed when Django’s documentation suggested putting models in a single file, and I took a few minutes from the very beginning to figure out how to split it into a proper subpackage.
site/models/__init__.py
site/models/book.py
__init__.py looks like:
from .book import Book
so I can still write “from site.models import Book”.
The following is only required for versions prior to Django 1.7, see
https://code.djangoproject.com/ticket/3591
The only trick is that you need to explicitly set each model’s application, due to a bug in Django: it assumes that the application name is the third-to-last entry in the model path. “site.models.Book” results in “site”, which is correct; “site.models.book.Book” makes it think the application name is “models”. This is a pretty nasty hack on Django’s part; it should probably search the list of installed applications for a prefix match.
class Book(models.Model):
class Meta: app_label = "site"
You could probably use a base class or metaclass to generalize this, but I haven’t bothered with that yet.
I can’t quite get which of many possible problems you might have. Here are some possibilities with answers:
-
multiple models in the same file
Put them into separate files. If there are dependencies, use import to pull in the
additional models.
-
extraneous logic / utility functions in models.py
Put the extra logic into separate files.
-
static methods for selecting some model instances from database
Create a new Manager in a separate file.
-
methods obviously related to the model
save, __unicode__ and get_absolute_url are examples.
Directions from my supervisor:
“I want to avoid putting any logic in the models.py. From here on out, let’s use that as only classes for accessing the database, and keep all logic in external classes that use the models classes, or wrap them.”
I feel like this is the wrong way to go. I feel that keeping logic out of the models just to keep the file small is a bad idea. If the logic is best in the model, that’s where it really should go regardless of file size.
So is there a simple way to just use includes? In PHP-speak, I’d like to propose to the supervisor that we just have models.py include() the model classes from other places. Conceptually, this would allow the models to have all the logic we want, yet keep file size down via increasing the number of files (which leads to less revision control problems like conflicts, etc.).
So, is there a simple way to remove model classes from the models.py file, but still have the models work with all of the Django tools? Or, is there a completely different yet elegant solution to the general problem of a “large” models.py file? Any input would be appreciated.
Django is designed to let you build many small applications instead of one big application.
Inside every large application are many small applications struggling to be free.
If your models.py feels big, you’re doing too much. Stop. Relax. Decompose.
Find smaller, potentially reusable small application components, or pieces. You don’t have to actually reuse them. Just think about them as potentially reusable.
Consider your upgrade paths and decompose applications that you might want to replace some day. You don’t have to actually replace them, but you can consider them as a stand-alone “module” of programming that might get replaced with something cooler in the future.
We have about a dozen applications, each model.py is no more than about 400 lines of code. They’re all pretty focused on less than about half-dozen discrete class definitions. (These aren’t hard limits, they’re observations about our code.)
We decompose early and often.
It’s natural for model classes to contain methods to operate on the model. If I have a Book model, with a method book.get_noun_count(), that’s where it belongs–I don’t want to have to write “get_noun_count(book)“, unless the method actually intrinsically belongs with some other package. (It might–for example, if I have a package for accessing Amazon’s API with “get_amazon_product_id(book)“.)
I cringed when Django’s documentation suggested putting models in a single file, and I took a few minutes from the very beginning to figure out how to split it into a proper subpackage.
site/models/__init__.py
site/models/book.py
__init__.py looks like:
from .book import Book
so I can still write “from site.models import Book”.
The following is only required for versions prior to Django 1.7, see
https://code.djangoproject.com/ticket/3591
The only trick is that you need to explicitly set each model’s application, due to a bug in Django: it assumes that the application name is the third-to-last entry in the model path. “site.models.Book” results in “site”, which is correct; “site.models.book.Book” makes it think the application name is “models”. This is a pretty nasty hack on Django’s part; it should probably search the list of installed applications for a prefix match.
class Book(models.Model):
class Meta: app_label = "site"
You could probably use a base class or metaclass to generalize this, but I haven’t bothered with that yet.
I can’t quite get which of many possible problems you might have. Here are some possibilities with answers:
-
multiple models in the same file
Put them into separate files. If there are dependencies, use import to pull in the
additional models. -
extraneous logic / utility functions in models.py
Put the extra logic into separate files.
-
static methods for selecting some model instances from database
Create a new Manager in a separate file.
-
methods obviously related to the model
save, __unicode__ and get_absolute_url are examples.