Some detours of Django project structure


My path of learning Python may be different from that of most people. At that time, my leaders arranged tasks to build an operation and maintenance platform and so on. At that time, I was still a rookie who could only write shell. After a week’s investigation, we found that Python is easy to use and Django framework is more comprehensive, so we looked at Django documents directly. So it is generally: the function of construction idea realization, how to realize Google function in Django, try to write it yourself, continue to Google when encountering problems, and repeat this process until the function you want to realize is completed. This kind of learning method can quickly achieve the goal of work. It is a top-down learning method. It is different from the bottom-up learning method, that is, the basic knowledge is not solid enough. Up to now, we have basically understood it. Let’s sum up the detour.

Demo project

Project structure

First of all, I think the structure of a project is the most important. Just like the human skeleton, a clear project structure is conducive to the separation and reuse of modules, and it is a kind of enjoyment for yourself or the people watching your code.

In the early days, my projects were all in the root project, and the code I wrote was all in the root projectviews.pyThis file will soon exceed 2K lines, and each time you open it, you need to wait for a while. Even some plug-ins of pychar are on strike (files larger than 1000 lines will be ignored due to operational efficiency problems).

After a period of exploration and review of open source projects, the following structure is more suitable for me.

  • Project structure document

    The following contents are key

    • For all the business logic implemented by apps, each module has a separate app to write, and the relevant logic is put into the corresponding app
    • Main root project, framework start entry. No business logic is implemented. A fixed name is called main.
    • Env project configuration directory, which contains a project configuration instance. It is usually mounted as a file through a container.
  • App structure

    Some detours of Django project structure

    •,urls.pyDo not write to a single file, otherwise once the number of interfaces becomes more and more difficult to maintain, open and place them in different files( Before a long time can only rely on Ctrl + F search…)
    • Filter method, Serializer methodDon’t talk to memodelsWrite them together and put them in separate files.
    • Extract the reusable functions of app and encapsulate them into tool classes. I didutilsIt is also said on the Internet to build onecommon.pyThe truth is the same.

For example, when I want to find the API of [user management] – > [background system], I can quickly locate itapps -> user -> urls -> http -> systemYou don’t have to go to a big oneviews.pyUse search in

Summary: the module configuration and function of the same function are extracted and put into a separate file.

Put in a general picture

Some detours of Django project structure

This work adoptsCC agreementReprint must indicate the author and the link of this article

Recommended Today

What is “hybrid cloud”?

In this paper, we define the concept of “hybrid cloud”, explain four different cloud deployment models of hybrid cloud, and deeply analyze the industrial trend of hybrid cloud through a series of data and charts. 01 introduction Hybrid cloud is a computing environment that integrates multiple platforms and data centers. Generally speaking, hybrid cloud is […]