# categorizing models in own files instead of models.py

**URL:** <https://forum.djangoproject.com/t/categorizing-models-in-own-files-instead-of-models-py/26277>\
**Category:** Getting Started\
**Created:** [December 19, 2023, 8:50am UTC](https://forum.djangoproject.com/t/categorizing-models-in-own-files-instead-of-models-py/26277 "2023-12-19T08:50:47Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![anjanesh](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/anjanesh/32/4583_2.png) [@anjanesh](https://forum.djangoproject.com/u/anjanesh)\
**Post date:** [December 19, 2023, 8:50am UTC](https://forum.djangoproject.com/t/categorizing-models-in-own-files-instead-of-models-py/26277/1 "2023-12-19T08:50:47Z")

</div>

My models.py is spanning 2000 lines with scores of model classes - is there some standard convention to keep each class in separate model files ? And how do we import the whole 20+ models in the models.py file ?

---

<div class="post-metadata">

**Author:** ![addwebsolution](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/addwebsolution/32/23762_2.png) [@addwebsolution](https://forum.djangoproject.com/u/addwebsolution)\
**Post date:** [December 19, 2023, 9:09am UTC](https://forum.djangoproject.com/t/categorizing-models-in-own-files-instead-of-models-py/26277/2 "2023-12-19T09:09:46Z")

</div>

Yes there is a way, You can create a separate file like separate\_models.py that have models A, B, C. Then in your models.py just import it and run migrations command it will be migrated and work like rest of your models defined in models.py.

Note: Just Import your separate\_models in models.py and run migrations command, Also in your admin.py you can register these models same as you do with models.py models.

```auto
from .separate_models import (
    A, B, C, etc...
)

```

---

<div class="post-metadata">

**Author:** ![HamaBarhamou](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/hamabarhamou/32/18007_2.png) [@HamaBarhamou](https://forum.djangoproject.com/u/HamaBarhamou)\
**Post date:** [December 19, 2023, 10:06am UTC](https://forum.djangoproject.com/t/categorizing-models-in-own-files-instead-of-models-py/26277/3 "2023-12-19T10:06:41Z")

</div>

I don’t see why you shouldn’t be able to do it, even though I didn’t have to do it myself. It must be no different to import a model from another application for use in your own model. In the same folder as your `models.py,` create your files `modelA.py` `modelB.py`…  
then use them in `models.py`, that should do the trick.

---

<div class="post-metadata">

**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\
**Post date:** [December 19, 2023, 1:54pm UTC](https://forum.djangoproject.com/t/categorizing-models-in-own-files-instead-of-models-py/26277/4 "2023-12-19T13:54:25Z")

</div>

See [CookBookSplitModelsToFiles – Django](https://code.djangoproject.com/wiki/CookBookSplitModelsToFiles)

Yes, the reference is old, and their note regarding the Meta class no longer applies, but this is a standard pattern for creating a module for models instead of a single file.

(Side note: Please do your developers a favor and do _not_ make this 1 model per file. Python is not Java. At a minimum allow for some common groupings of directly related models in a common file. Your developers will thank you for it.)

---

<div class="post-metadata">

**Author:** ![HamaBarhamou](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/hamabarhamou/32/18007_2.png) [@HamaBarhamou](https://forum.djangoproject.com/u/HamaBarhamou)\
**Post date:** [December 19, 2023, 4:28pm UTC](https://forum.djangoproject.com/t/categorizing-models-in-own-files-instead-of-models-py/26277/5 "2023-12-19T16:28:11Z")

</div>

Thank you for your feedback, @KenWhitesell . I understand that my proposal to split models into multiple files might seem counterintuitive, and I acknowledge your concerns about logically grouping models. However, I’d like to understand better why this approach could be problematic. In my understanding, Django does not restrict us to one model per file - it’s entirely feasible to distribute models across multiple files for clarity and organization, especially in larger projects. For instance, in a large project, we might have separate files such as order\_models.py, customer\_models.py, etc., grouping related models logically, while then importing them into models.py for centralized management. This method seems to be a common practice for managing complex projects, improving readability and maintainability. That said, I’m open to your insights and experiences on why this approach might not be ideal, or how it could be improved."

Project structure example:

```auto
myapp/
    __init__.py
    models/
        __init__.py
        user.py
        product.py
        order.py
        ...

```

`myapp/models/user.py`:

```auto
from django.db import models

class User(models.Model):
    # Define User model fields and behavior here
    ...

```

`myapp/models/product.py`:

```auto
from django.db import models

class Product(models.Model):
    # Define Product model fields and behavior here
    ...

```

In `myapp/models/order.py`:

pythonCopy code

```auto
from django.db import models

class Order(models.Model):
    # Define Order model fields and behavior here
    ...

```

And finally, in `myapp/models/ __init__.py`:

```auto
from .user import User
from .product import Product
from .order import Order
# Import other models here as needed
...

```

With this structure, each model is placed in its own file for better organization and clarity, especially in large projects. Each model is then imported into the ` __init__.py` file for centralized management and simplified importing into other parts of the application. This approach allows for maintaining smaller, more manageable model files while offering flexibility for future project growth.

---

<div class="post-metadata">

**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\
**Post date:** [December 19, 2023, 5:12pm UTC](https://forum.djangoproject.com/t/categorizing-models-in-own-files-instead-of-models-py/26277/6 "2023-12-19T17:12:48Z")

</div>

> [@HamaBarhamou](#):
>
> However, I’d like to understand better why this approach could be problematic.

My experience has been that “clarity and organization” - _especially_ in larger projects, is _not_ enhanced by dramatically increasing the number of files involved. In fact, I have found the exact opposite to be true.

We don’t even begin to think about splitting apart our models.py files until they’re at least 2000 lines, and will let them get to about 2500 before taking action. (And, in some cases - typically when external databases are involved, that “action” ends up being “do nothing” because we recognize there’s no benefit in _those_ cases by splitting up the models.)

And, in those cases where we do choose to do something, as often as not it ends up being a situation where we split a whole chunk of functionality off as a separate app.

> [@HamaBarhamou](#):
>
> With this structure, each model is placed in its own file for better organization and clarity, especially in large projects.

I can respect the fact that you have that opinion. We (the development team I am a part of) don’t share that opinion and disagree with the conclusion. We all have backgrounds with large Java-based projects and have concluded that the “one-class-per-file” default standard is extremely counter-productive and have found much practical benefit in the “fewer-files-are-better” approach.

---

<div class="post-metadata">

**Author:** ![HamaBarhamou](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/hamabarhamou/32/18007_2.png) [@HamaBarhamou](https://forum.djangoproject.com/u/HamaBarhamou)\
**Post date:** [December 19, 2023, 6:53pm UTC](https://forum.djangoproject.com/t/categorizing-models-in-own-files-instead-of-models-py/26277/8 "2023-12-19T18:53:25Z")

</div>

Dear @KenWhitesell ,

Thank you for your detailed response and for sharing your experience with managing large Django projects. Your insights on the impact of increasing file numbers on clarity and organization are very pertinent.

I understand your perspective that splitting a `models.py` file into several smaller files does not always guarantee improved readability or maintainability, especially in complex projects. However, my initial proposition was to explore the technical feasibility of separating models into distinct files within Django, not necessarily to debate its practical efficacy. To my understanding, Django technically allows this separation, although it is not a common or recommended practice in the Django community.

I fully respect your approach of functionally dividing functionalities into different applications when justified, which is different from my suggestion of distributing models across multiple files within the same application for clarity in specific cases. Your advice to favor fewer files for better overall management is well taken and will surely be helpful to many developers.

Once again, thank you for your time and for sharing your valuable insights. Your contributions greatly enhance our collective understanding of best practices in Django development.

Best regards.

---

<div class="post-metadata">

**Author:** ![pjrulez](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/pjrulez/32/23826_2.png) [@pjrulez](https://forum.djangoproject.com/u/pjrulez)\
**Post date:** [November 20, 2024, 12:06am UTC](https://forum.djangoproject.com/t/categorizing-models-in-own-files-instead-of-models-py/26277/9 "2024-11-20T00:06:36Z")

</div>

Similarly, I would like to separate model Manager classes into managers.py, instead of keeping them in models.py. Then I could see the Model, and its Manager side by side if I wanted to.

Somehow I’m unable to make it happen without running into circular dependencies or ending up with Managers that throw such errors: AttributeError: ‘Manager’ object has no attribute ‘get\_by\_zone\_name’

Is there a way to get this done? I tried apps.get\_model and Meta proxy = True but without success.