POO using Django

Question

I’m starting to work with Django, but I’m having some doubts about how to organize my project, I would like to know the best way to structure my projects.

I’m used to the languages in which I model each entity with its attributes and methods in a class that stays in only one file, but in Django what I see is that I just have a view that inside I define several classes. This is the right way ?

I saw that some people create an App for each entity, this would be what gets closer than I’m used to, but it’s a correct way ?

Answer 1

No, it’s not the right way.

Simply put, Jango works with apps. Every app you create on your system should follow the context of something. For example: If in my system I have the following models:

Cliente
Produto
CategoriaProduto
Venda
ItensVenda

In this case, you can have 3 apps on the system:

• Customers #app customers
  • Client
• Products # app products
  • Product
  • Categoriaproduto
• Sales # app sales
  • Sale
  • Itensvenda

You can put 50 templates in an app the same way you can put 1 template in an app. Two Scoops of Django (a book about Jango’s best practices) says that if you have more than 5 models in an app, you should split your app in two. If you have a very generic model that can be used on multiple systems, you can have an app just for it. This will make your life a lot easier. For example: "Category" is something that can be used in several systems, what changes is the context of the category. In a sales system is product category, in a service system is the type of service..

It is not something that should be taken to heart, but you have to keep in mind that every thing must be in its place. And to work in a modularized way, means that each thing must be in its proper place. This will help in the refactoring and maintenance of the code.

I had the misfortune of working on code that the old developers created a single "core" app and played all the models of the project inside. This is very bad because you have thousands of things stored in the same place. Then to see something in the project, file up... file down.. goes up again to see if it imported something.

On the view question, Django works with the structure "MVT", Model, View and Template. In this medium has its forms as well.

I like to explain this way (in a very basic way):

• Model: Responsible for the system classes, the bees that will go to the database.
• Forms: Responsible for "what" will be presented and how it will be presented (referring to models).
• View: Responsible for sending and receiving your requests.

I can’t say you’re wrong to say you have classes in your views because if you’re working with Class Based View, you’ll have classes in your views. If you are on this path, I recommend going initially through Function Based View and then skip to CBV.

About the architecture of the project itself, you can organize this way:

project/
    clientes/
        models.py
        views.py
        ...
    produtos/
    project/
        settings.py
        urls.py
        ....
    vendas/

A well-modularized project and good practice is incredibly easier to read and understand. You should make your code so that if another developer works on it, he sees that you cared about the quality of the code.