This is the third day of my participation in Gwen Challenge

Django is a Web framework for Python. Pretty short and fast for a startup. As the business grows, more and more code will be added. If you don’t have a good plan for the project catalog at the beginning, then you’re basically rewriting rather than refactoring.

Although Python3.5 started with type hits, it was a bit of a bug, and that could only be called a variable type annotation without any impact on the runtime. However, it is recommended to use with pyright because the djangorestframework framework is called DRF for short due to its long name

Let’s start with a Django project

We first set up a gold digging project and demo app based on Django2.2.10.

PIP install django = = 2.2.10

pip install djangorestframework

Create a juejin project django-admin startProject juejin

Python juejin/manage.py startApp demo

Let’s modify INSTALLED_APPS

Run first

We can see the current project directory below.

There will be two more files under DRF. Serializers. Py and filters.py are used for serialization and ORM filtering.

For previous projects, you can write them all in one directory. But be careful when a file is more than 500 lines long. You should start thinking about splitting, rather than continuing to write down the directory, because the more you write, the more time you need to decouple later.

Which file will swell now/in the future? Then split it out and create a separate folder. Views are used as an example. I set up two viewset codes, namely articles and hot news, and split them in advance to plan.

Views on Service

This was discussed in another tech community. If you are interested, please refer to the link below.

But for Django development, because Django is designed to be MVT

Model Data -> View View () -> Template Template

This is sufficient for small projects because there are not many page templates. But if the project becomes medium or large, it’s a little stretched. Because there will be a bunch of code will be written into the views file.

It is recommended for the Service layer (folder/file) to decouple the code at the views level.

A service should be passed from Java, which is not a natural fit for Django, but if you continue to write your code to a single file. It makes the code unmaintainable. Django can be blended with the right elements of other language frameworks to make it work best.

Some advice

Validation data is only available in serializers; views are only available in the loop.

Data processing should be done through the Service instead of writing directly to the view, keeping the view’s output interface.

App needs to be split in advance, otherwise the later coupling is too strong for splitting.

When using migrate, you should consider the fields before migrating. Djangos data migration is easy, but this convenience can be a double-edged sword later on as fields become too many. Especially when the fields on the test server are out of sync with those on the official server, which may result in data migration, be careful.

See this article for a list of problems with building an APP server using Django

Found a little nugget egg

It’s in the edit article console