Роль фильтров Django. Фильтрация или предварительное форматирование в представлении?

Question

Хотелось бы услышать ваше мнение по этому поводу.

У меня есть приложение django, где данные, полученные из модели, являются грубыми. Чтобы сделать их лучше, я должен выполнить потенциально сложную, но не слишком сложную операцию. Например, предположим, у вас есть модель, в которой штат США кодируется в виде двухбуквенных кодов. В html-рендеринге вы хотите предоставить пользователю полное имя состояния. У меня есть переписка из двух букв -> полное имя в другой таблице БД. Давайте предположим, что я не хочу выполнять объединения.

У меня есть два варианта

1. заставить код представления извлечь двухбуквенную информацию из модели, затем выполнить запрос ко второй таблице, получить полное имя и поместить его в контекст. Шаблон отображает полное имя состояния.
2. создать пользовательский фильтр, который принимает двухбуквенные коды, нажимает на БД и возвращает полное имя. Пусть представление передаст двухбуквенную информацию в контекст и вставит шаблон в трубопровод. Фильтр отображает двухбуквенный код в виде полной строки.

Теперь, эти решения кажутся эквивалентными, но они не могут быть, также с точки зрения дизайна. Я скептически отношусь к тому, где провести грань между ответственностью фильтра и ответственностью просмотра. Решение 1 выполняет задачу фильтра в решении 2, он просто интегрирован в само представление. Конечно, если мне придется вызывать фильтр несколько раз на одной и той же странице, решение 1, вероятно, будет быстрее (если выходные данные фильтра не запомнены).

Что вы думаете о дизайне, правильном кодировании и производительности?

Answer 1

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

Лучше иметь всю "логику вычислений" в представлении. Вот, кстати:

• Гораздо проще прочитать и понять (особенно для третьей стороны).

• Если вам нужно изменить что-то, вы можете сосредоточиться на конкретном методе представления и быть уверенным, что все, что вам нужно изменить, присутствует (нет необходимости переключаться назад и вперед из представления шаблон).

Что касается производительности, я думаю, что вы правы. Если вы хотите выполнить один и тот же поиск несколько раз, второе решение хуже.

Редактировать : Ссылаясь на комментарий Ашристофера, я на самом деле пытался сказать, что он определенно не относится к шаблону. Никогда не ясно, что такое бизнес-логика и где находится грань между « предоставлением данных » и « бизнес-логикой ». В этом случае кажется, что, возможно, Ашристофер прав. Преобразование кодов состояний в полные имена состояний, вероятно, в большей степени относится к кодированию, связанному с базой данных, чем к бизнес-логике.

Answer 2

Мне кажется, что ваша модель должна иметь метод для преобразования. Создание фильтра кажется дополнительной работой, и я не думаю, что большинство разработчиков Django ожидают такого в фильтре.

Фильтр должен быть более общим - форматировать и отображать данные, а не искать.