Джанго: толстые модели и тощие контроллеры?

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

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

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

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

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

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

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

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

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