MVC не является универсальным решением, и большую часть времени он выполняется неправильно и не может выполнить свои обещания: на практике изменение модели также потребует изменений в контроллере, потому что это сделано неправильно. Если вам действительно нужна слабая связь между моделью и контроллером - и люди обычно игнорируют это - вы должны использовать шаблон обслуживания (открыть как изображение) . Что на самом деле почти никто не делает.
Вместо слепого следования суете / псевдо-шаблону MVC в мире PHP, Django использует прагматический подход . Потому что в обычной реальности разработки программного обеспечения разработчик программирует вещи, которые должен видеть пользователь. Тогда пользователь (ваш начальник, клиент, клиенты ...) увидит вашу работу и в конечном итоге выскажет свое мнение о том, как он хочет ее увидеть в конце. Используя Django, разработчик может взять более «ориентированный на взгляд» шаблон разработки и угадать, что: это облегчает соблюдение сроков и удовлетворение пользователей. Если вы думаете об этом, у него есть идея «nosql-ish», что представление (общий вид, а не представление django) должно быть боссом того, что происходит за кулисами.
Я хотел бы поблагодарить Django за то, что он не сделал MVC неправильно, в отличие от 99% реализаций PHP MVC там.
С другой стороны, Django является единственной платформой, которая обеспечивает надлежащую изоляцию между приложениями. Каждое приложение может иметь:
- Модель
- вид
- Шаблоны
- 1022 * URLs *
- статические файлы
- Тесты
- Формы
- необязательные дополнения (администраторы, фильтры для ajax-select, разрешения для django-полномочий, уведомления для django-уведомлений и т. Д. И т. Д.)
Таким образом, даже если ваши модели / представления / шаблоны будут связаны, ваш проект можно соответствующим образом разделить на небольшие (также легко читаемые) и слабо связанные приложения. Только связанные модели / виды / шаблоны / вещи связаны между собой. Сценарий с большими жирными моделями с большими жирными сценариями и URL-адресами - это не то, что вам нужно в Django. Например, вы не хотите, чтобы два класса моделей, такие как Article и FootballMatch, жили вместе, вы хотите создать приложение «статьи» / «блог» и приложение «спорт», которые могут жить независимо. Конечно, иногда они должны быть связаны, в этом случае это выполнимо на уровне проекта в 90% случаев (вы бы создали другое приложение, «blog_sport», если вам понадобилось связать модели или теги-шаблоны).
Например, это очень распространенная практика - определять метод get_absolute_url () в классе Model. Да, ваш класс модели, который теоретически должен содержать только бизнес-логику, теперь связан с вашим определением URL. Насколько это плохо на практике? !! На самом деле это великолепно, потому что для добавления этого метода требуется две секунды, и вы можете использовать его везде, где используете модель: будь то в представлениях или шаблонах. Кроме того, другие приложения (например, django.contrib.admin) будут использовать его.
Еще один немного более сложный пример блеска Django заключается в том, что запросы лениво оцениваются. Это означает, что ваша функция / класс представления определит запрос, например blog_list = Blog.objects.all (), но запрос будет фактически выполнен в шаблоне, если он вызовет значение {% для блога в blog_list%}. Таким образом, бизнес-логика в этом случае происходит в шаблоне, и если что-то не удается до отображения шаблона: вы сохранили запрос. Но это еще не все, если ваш шаблон просто отображает счетчик {{blog_list.count}}, запрос select не будет вызван вообще и будет выполнен только запрос счета. «Общий вид» решает, какая бизнес-логика необходима. Это далеко от обещаний MVC, но, честно говоря, насколько это практично?
Я хочу сказать, что вы можете применять теорию неправильно, делать это правильно (что ограничивает ваш выбор, например, 5 web фреймворки на всех языках), или просто перейти к сути в элегантном и прагматичном способ выполнить свою работу в дзен в кратчайшие сроки: это выбор Джанго.