Почему я должен использовать шаблон MVC?

Кажется, что сегодня все, кто занимается веб-приложениями, хотят использовать MVC для всего. Однако мне трудно убедить себя в использовании этого паттерна. Я понимаю, что основная идея состоит в том, чтобы отделить логику бэкэнда от внешнего интерфейса, представляющего программу. Как правило, кажется, что представления всегда в некоторой степени зависят от контроллера, что в конечном итоге зависит от модели. Я не вижу, какое преимущество дает мне добавление контроллера. Я читал много шумихи по поводу того, «именно так должны разрабатываться приложения», но, возможно, я до сих пор не понимаю, что и куда должно идти. Всякий раз, когда я разговариваю с другими о MVC, кажется, что у всех разные представления о том, что относится к какой категории.

Итак, почему я должен использовать MVC? Что я получу, используя MVC, просто отделяя интерфейс от логики бэкенда? (Большинство «преимуществ», которые я вижу в этом шаблоне, получаются только путем отделения интерфейса от реализации и не объясняют цель наличия отдельного «контроллера»)

Хех. Мартин Фаулер согласен с вашей путаницей в отношении MVC:

Я не считаю ужасно полезным думать о MVC как о шаблоне, потому что он содержит довольно много разных идей. Разные люди, читающие о MVC в разных местах, берут из этого разные идеи и называют их «MVC». Если это не вызывает достаточно путаницы, вы получите эффект недопонимания MVC, которое развивается через систему китайских шепотов.

Однако он продолжает давать одно из более убедительных объяснений того, что мотивирует MVC:

В основе MVC лежит то, что я называю отдельной презентацией. Идея, стоящая за разделенной презентацией, состоит в том, чтобы сделать четкое разделение между объектами домена, которые моделируют наше восприятие реального мира, и объектами презентации, которые являются элементами графического интерфейса, которые мы видим на экране. Доменные объекты должны быть полностью автономными и работать без ссылки на презентацию, они также должны поддерживать несколько презентаций, возможно, одновременно.

Вы можете прочитать всю статью Фаулера здесь .

Я чувствую, что это во многом зависит от проблемы, которую вы решаете. Я вижу разделение следующим образом:

Модель - как мы представляем данные? Например, как мне перейти от моих объектов к постоянному хранилищу, например, к БД -> как сохранить мой объект «Пользователь» в базе данных?

Контроллер - что я делаю? Это действие, которое происходит, и что на концептуальном уровне необходимо выполнить. Например, какие этапы мне нужно пройти, чтобы выставить счет пользователю? NB это может повлиять на любое количество объектов, но ничего не знает о том, как они сохраняются в БД.

Просмотр - как мне отрендерить результат?

Проблема, которую я чувствую, вы видите в том, что многие веб-приложения представляют собой прославленный CRUD-интерфейс (Create-Retrieve-Update-Delete) для БД. то есть контроллеру говорят «добавить пользователя», а затем он просто говорит модели «добавить пользователя». Ничего не получено.

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

Ты не должен.

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

Исходя из CI и Yii, я думал, что иметь выделенный контроллер было действительно крутой идеей. Однако при разработке приложений с надлежащими интерфейсами RESTful потребность в контроллере для обработки логики, не зависящей от модели, кажется, уменьшается. Таким образом, при переходе на Django, а затем на Pyramid (ни один из которых не полностью соответствует архитектуре MVC), я обнаружил, что контроллер на самом деле не был обязательным компонентом для приложений, которые я создавал. Обратите внимание, что обе платформы имеют функции контроллера, такие как диспетчеризация URL в Pyramid, но это конфигурация, а не среда выполнения (например, CController в Yii).

В конце концов, что действительно важно, так это отделение взгляда от логики. Это не только очищает вещи с точки зрения реализации, но также позволяет инженерам FE / BE работать параллельно (при работе в командной среде).

(Примечание: я не занимаюсь разработкой веб-приложений профессионально, поэтому, возможно, мне чего-то не хватает)

Да, терминология по этому вопросу - беспорядок. Трудно говорить, потому что вы никогда не понимаете, что кто-то подразумевает под терминами.

Относительно того, почему отдельный контроллер, причина может зависеть от того, о какой версии контроллера вы говорите.

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

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

Проще говоря: разделение интересов. Помимо всех разговоров о «правильном» способе ведения дел, наличии более чистого кода и т. Д., Вы можете просто сказать, что MVC позволяет вам более легко повторно использовать ваш код. По сути, вы программируете свои модели и свои контроллеры, и вы можете нечетко использовать их в веб-приложении, настольном приложении, сервисе в любом месте без особых усилий.

Итак, основная причина использования структуры MVC проявляется в промышленных настройках, где для разработки любого приложения используется один рабочий процесс, единая модель. Таким образом, в случае, если проект переходит от одного модуля организации к другому, гораздо проще обеспечить лучшее понимание сценария работы. Это включает в себя ясность работы.
Хотя у вас, как у отдельного человека, будет другой подход к вашему заявлению, вы, работая в комбинированном режиме с партнером, сначала обсудите и согласитесь на общепринятую модель, предложенную обеими сторонами (вами и вашим партнером). И в таком случае он разделяет обязанности, возложенные на вас и вашего сотрудника, соответственно, с определенной разницей.

Я думаю, что MVC используется просто модным словом теоретиками, которые являются менеджерами. Тем не менее, сказав, что текущая итерация сети с HTML5 преобладает, адаптивный дизайн и пытается создать единую линию программирования баз данных, которая будет работать в Интернете и на iPhone, подпадает под общие идеи MVC. Технология веб-интерфейса буквально движется со скоростью света прямо сейчас с Jquery, новыми итерациями управления CSS, тогда как серверная часть вещей движется со скоростью улитки.

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

В этом отношении, я полагаю, что в текущем реальном мире MVVM - действительно лучший «шаблон» или как вы хотите его называть, чем контроллер, потому что контроллер всегда должен возвращаться к модели, чтобы изменить представление, и это медленно. , В шаблоне MVVM ViewModel может немедленно обновить представление. Кроме того, модель MVVM поддерживает принципы дизайна RESTful IMHO.