Django: Жирные модели и тощие контроллеры?

Ответ 1

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

Вместо того, чтобы слепо придерживаться сумасшествия MVC/псевдо-шаблона в мире PHP, Django использует прагматический подход. Потому что в общей реальности разработки программного обеспечения разработчик программирует вещи для просмотра пользователем. Тогда пользователь (ваш босс, клиент, клиенты...) "увидит" вашу работу и, в конце концов, даст свое мнение о том, как он хочет "увидеть" ее в конце. Используя Django, разработчик может использовать более "ориентированный на взгляд" шаблон разработки и угадывать, что: он упрощает соблюдение сроков, а пользователи более довольны. Если вы думаете об этом, у него есть идея "nosql-ish" о том, что представление (общий вид, а не представление django) должно быть боссом того, что происходит за кулисами.

Я хочу поблагодарить Django за то, что он не ошибался в MVC, в отличие от 99% реализаций PHP MVC.

С другой стороны, Django является единственной структурой, которая обеспечивает надлежащую изоляцию между приложениями. Каждое приложение может иметь:

• Модели
• вид
• Шаблоны
• URLs
• статические файлы
• Тесты
• формы
• дополнительные аддоны (админы, фильтры для ajax-selects, разрешения для django-полномочий, уведомления для django-уведомлений и т.д.) и /

Таким образом, даже если ваши модели/представления/шаблоны будут привязаны, ваш проект может быть соответствующим образом разделен на небольшие (также читаемые: простые в обслуживании) и слабосвязанные приложения. Только связанные модели/представления/шаблоны/материал связаны друг с другом. Большие толстые модели script с большими толстыми видами и URL script - это не то, что вы хотите в Django. Например, вы не хотите, чтобы два модельных класса, таких как Article и FootballMatch, жили вместе, вы хотите создать приложение "статьи" / "блог" и приложение "спорт", которое может жить независимо. Конечно, иногда они должны быть привязаны, в этом случае это выполнимо на уровне проекта в 90% случаев (вы бы сделали другое приложение "blog_sport", если вам нужно было привязать модели или templatetags).

Например, это очень обычная практика для определения метода get_absolute_url() в классе Model. Да, ваш модельный класс, который теоретически должен содержать только бизнес-логику, теперь привязан к вашему определению URL. Насколько это плохо на практике?!! Ну, на самом деле это блестяще, потому что для добавления этого метода требуется две секунды, и вы можете использовать его везде, где вы используете модель: будь то в виде или шаблонах. Кроме того, будут использоваться другие приложения (например, django.contrib.admin).

Еще один более сложный пример блеска Django заключается в том, что запросы лениво оцениваются. Это означает, что ваша функция view/class будет определять такой запрос, как blog_list = Blog.objects.all(), но запрос будет фактически выполнен в шаблоне, если он называет это как% для блога в blog_list%}. Таким образом, бизнес-логика возникает в шаблоне в этом случае, и если что-то не удается выполнить рендеринг шаблона: вы сохранили запрос. Но это не все, если ваш шаблон просто отображает счет {{blog_list.count}}, запрос выбора не будет порожден вообще, и будет выполнен только запрос на подсчет. "Общий вид" определяет, какая бизнес-логика необходима. Что далеко от promises MVC, но быть честным: насколько это практично?

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

Ответ 2

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

Если вы считаете, что какая-то логика сильно связана с вашей моделью, вы можете создать ее метод. Правило (для меня) заключается в том, что ваша модель должна быть агностикой в ​​отношении среды (веб-приложение, Crontab, управляющее командой управления и т.д.).

Моя политика - попытаться установить минимальный минимум в моих моделях.

Кстати, вы не планируете обрабатывать request и sessions в своих моделях, не так ли? это плохая идея.

Ответ 3

Моя самая большая проблема с Django заключается в том, что они разбивают шаблон MVC, добавляя слой Forms. Большая часть документации побуждает вас размещать логику проверки в формах, а тот факт, что модель валидаторы вызывается только формой, только усиливает это соглашение. По-моему, это плохое соглашение, потому что, в конце концов, слишком часто проверяемые данные являются данными, которые будут преобразованы в модель.

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

Я думаю, что подход толстых моделей - это путь. Подробнее о том, как его реализовать в Django здесь.