бизнес-логика в Django

Question

Я хотел бы знать, где поставить код, который не принадлежит к виду, я имею в виду логику.

Я читал несколько подобных сообщений, но не смог прийти к выводу.

Что я мог понять:

• взгляд, как контроллер, и много логики не следует ставить в контроллере.
• Модели также не должны иметь много логики.

Итак, где же все должно существовать на основе логики?

Я родом из Groovy/Grails и, например, если нам нужно получить доступ к БД или если у нас сложная логика, мы используем сервисы, а затем эти службы вводятся в контроллеры.

Хорошая практика иметь .py файлы, содержащие вещи, отличные от представлений и моделей в Django?

PS: Я читал, что некоторые люди используют services.py, но другие люди говорят, что это плохая практика, так что я немного запутался ...

Answer 1

Короткий ответ: Джанго это больше из MTV или MVT (модель/шаблон/вид), как описано в официальном FAQ: https://docs.djangoproject.com/en/dev/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names

Бизнес-логика имеет свое место в ваших взглядах, но ничто не мешает вам вставлять ее в «utils.py», «services» .py "или что-нибудь по своему вкусу.

Answer 2

Если функциональность хорошо подходит как метод некоторого экземпляра модели, поставьте его там. В конце концов, модели - это просто классы.

В противном случае просто напишите модуль Python (некоторый .py-файл) и поместите туда код, как и в любой другой библиотеке Python.

Не помещайте его во взгляды. Представления должны быть единственной частью вашего кода, которая знает HTTP, и они должны оставаться как можно меньше.

Answer 3

Я не знаю, почему вы говорите

мы не можем поставить много логики в контроллере, и мы не можем иметь модели с большим количеством логики либо

You безусловно, может поставить логику в любом из этих мест. В значительной степени это зависит от того, что такое логика: если она специально связана с одним классом модели, она должна идти в модели. Если, однако, он больше связан с конкретной страницей, он может пойти в точку зрения.

В качестве альтернативы, если это более общая логика, используемая в нескольких представлениях, вы можете поместить ее в отдельный служебный модуль. Или вы можете использовать представления на основе класса с суперклассом, который определяет логику и подклассы, которые наследуются от нее.

Answer 4

Имея java-фон, я могу связать этот вопрос. Я уже давно работаю над python. Несмотря на то, что я стараюсь рассматривать Java как Java и Python как Python, я иногда смешиваю их и для того, чтобы я мог получить хорошую прибыль от обоих.

Короче

1. Поместить все связанные модели вещи в модели приложения, это может быть от просто определения моделей на заказ сохранить, предварительно сохранить крючки .....

2. Поместите любой запрос/связанный с ответом материал в представлениях и некоторая логика, как проверка схемы Джона, проверка запроса тела ... обработки исключений и т. д.

3. Поместите свою бизнес-логику в отдельную папку/приложение или модуль на каталог/приложение для просмотров. , Значение имеет отдельный средний модуль между вашими моделями и представлениями.

Существует не строгое правило для организации вашего кода, если вы согласны.

Проект: Ci

• модели: CI/модель/device.py

• Просмотров: кюри/просмотров/list_device.py

• Бизнес логика:

  • (1) ci/business_logic /discover_device.py

    Или

  • (2) Ки/просмотров/discover_device.py