Логика приложения в коде представления

Question

Должен ли я писать логику приложения в коде моего представления?Например, при отправке элемента формы мне нужно создать пользователя и отправить ему электронное письмо для активации.Это что-то делать из функции представления, или я должен создать отдельную функцию, чтобы облегчить тестирование в будущем?Что Django рекомендует здесь?

Answer 1

Мне было очень трудно понять, куда все идет, когда я начал использовать django. Это действительно зависит от типа логики, которую вы пишете.

Сначала начните с моделей: методы и менеджеры моделей - это хорошее место для выполнения логики на уровне строк и логики на уровне таблиц, то есть менеджер моделей был бы хорошим местом для написания кода для получения списка категорий, связанных с все посты Модельный метод - это хорошее место для подсчета символов в определенном посте.

Логика уровня представления должна иметь дело со сборкой всего этого - принятием запроса, выполнением необходимых шагов для достижения необходимого результата (возможно, с использованием менеджеров моделей) и затем подготовкой его к шаблону.

Если есть код, который не вписывается в другое место, но имеет логическую структуру, вы можете просто написать модуль для его выполнения. Точно так же, если есть клочки кода, которые, по вашему мнению, не принадлежат, сохраните файл utils.py для их хранения.

Вы не должны выполнять какую-либо логику в своих шаблонах - вместо этого используйте теги шаблона, если это необходимо. Они хороши для использования многократно используемых фрагментов кода, которые вам не нужны ни в каждом цикле запросов, ни в одном отдельном цикле запросов - вы можете захотеть, чтобы они были в подмножестве (т.е. отображать список категорий в разделе блога на вашем веб-сайте)

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

TLDR : Написание логики на ваш взгляд - это хорошо, но есть множество мест, которые могут быть более подходящими

Answer 2

Разделение регистрационного кода на его собственную функцию для облегчения тестирования является хорошей причиной.Если вы разрешите администраторам регистрировать пользователей в отдельном, приватном представлении, тогда функция регистрации будет более СУХОЙ.Лично я не думаю, что небольшая логика приложения в коде принесет много вреда.

Возможно, вам будет полезно взглянуть на представление регистрации в приложении django-registration - просто чтобы увидеть, как оно написано, я не говорю, что вы должны или должныиспользуй это.Он инкапсулировал регистрацию пользователя в свою собственную функцию (также существует уровень косвенности, поскольку бэкэнды регистрации являются подключаемыми).