#php #model-view-controller #web-applications #architecture
#php #модель-представление-контроллер #веб-приложения #архитектура
Вопрос:
Я изучал Zend и его структуру приложений MVC для своей новой работы и обнаружил, что работа с ним просто беспокоит меня по причинам, которые я не мог понять. Затем в ходе моих исследований я наткнулся на такие статьи, как MVC: нет серебряной пули и этот подкаст на тему MVC и веб-приложений. Парень в подкасте привел очень веские аргументы против MVC как архитектуры веб-приложений и рассказал о многом из того, что не давало мне покоя.
Однако остается вопрос: если MVC на самом деле не подходит для веб-приложений, что же тогда?
Комментарии:
1. Не могли бы вы написать одно или два предложения о том, что, по мнению подкаста, не так с MVC, чтобы читателям здесь не пришлось слушать это, чтобы понять основные возражения? Мне тоже должно быть интересно
:)2. Ссылка на подкаст не подлежит восстановлению (ничего в wayback machine). Она была заменена этой страницей , но ссылка на подкаст там также не работает. Однако, если вы ищете доклад «Почему MVC не является архитектурой приложения», вы получите эту видеопрезентацию того же человека.
Ответ №1:
Все зависит от вашего стиля кодирования. Вот секрет: невозможно написать классический MVC на PHP.
Любой фреймворк, который утверждает, что вы можете, лжет вам. Реальность такова, что сами фреймворки даже не могут реализовать MVC — ваш код может. Но, я думаю, это не такой хороший маркетинговый ход.
Для реализации классического MVC вам потребуется для начала иметь постоянные модели. Кроме того, модель должна информировать View об изменениях (шаблон наблюдателя), что тоже невозможно на вашей ванильной PHP-странице (вы можете сделать что-то близкое к классическому MVC, если используете сокеты, но это непрактично для реального веб-сайта).
В веб-разработке у вас на самом деле есть 4 других решения, основанных на MVC:
-
Model2 MVC: View запрашивает данные из модели, а затем решает, как их отображать и какие шаблоны использовать. Контроллер отвечает за изменение состояния как представления, так и модели.
-
MVVM: контроллер заменяется ViewModel, который отвечает за преобразование между ожиданиями представления и логикой моделей. Просмотр запрашивает данные у контроллера, который преобразует запрос, чтобы модель могла его понять.
Чаще всего вы используете это, когда у вас нет контроля ни над представлениями, ни над уровнем модели.
-
MVP (то, что фреймворки php называют «MVC»): Presenter запрашивает информацию у модели, собирает ее, изменяет и передает в пассивное представление.
Чтобы изучить этот шаблон, я бы рекомендовал вам начать с этой публикации. Это будет объяснено подробно.
-
HMVC (или PAC): отличается от Model2 способностью контроллера выполнять субконтроллеры. У каждого своя триада M, V и C. Вы получаете модульность и удобство обслуживания, но платите некоторым снижением производительности.
В любом случае. Суть в том, что вы на самом деле не использовали MVC.
Но если вам надоели все MVC-подобные структуры, вы можете заглянуть в:
- архитектуры, управляемые событиями
- n-уровневая архитектура
И тогда всегда есть парадигма DCI, но у нее есть некоторые проблемы при применении к PHP (вы не можете привести к классу в PHP .. не без уродливых хаков).
Комментарии:
1. Спасибо, они выглядят интересно. Особенно Model2. Я изучу их и посмотрю, какой из них лучше всего подходит для того, что я собираюсь сделать.
2.
"To implement a classical MVC it would require for you to have persistent Models to begin with.", что означает это предложение? Постоянный? Повторяющийся? Без каких-либо изменений? Делает ли это вывод"model without side-effects"или что-то совершенно другое?3. В классическом MVC представление наблюдает за моделью (или, если быть точным, структурами из уровня модели) . При изменении состояния модели представление запрашивает новую информацию. С «постоянной моделью» я имел в виду, что уровень модели существует, все думали об использовании приложения. Это невозможно в PHP, потому что при отправке ответа экземпляр из уровня модели уничтожается. Это ограничение архитектуры PHP без общего доступа. Для просмотра невозможно наблюдать за уровнем модели .. больше нечего наблюдать.
4. Выглядит многообещающей n-уровневой архитектурой
5. В качестве примечания: существуют (более или менее) сложные решения для включения постоянных сеансов в php, что, в свою очередь, позволит нам создавать постоянные модели. Это решение, с которым я знаком: us2.php.net/manual/en/intro.memcache.php
Ответ №2:
По моему опыту, преимущества, которые вы получаете от архитектуры MVC, намного перевешивают ее затраты и очевидные накладные расходы при разработке для Интернета.
Для кого-то, начинающего со сложной среды MVC, может быть немного сложно приложить дополнительные усилия для разделения трех уровней и получить хорошее представление о том, что где находится (некоторые вещи очевидны, другие могут быть довольно пограничными и, как правило, являются хорошими темами для обсуждения). Я думаю, что эта стоимость окупается в долгосрочной перспективе, особенно если вы ожидаете, что ваше приложение будет расти или поддерживаться в течение разумного периода времени.
У меня были ситуации, когда стоимость создания нового API, позволяющего другим клиентам подключаться к существующему веб-приложению, была чрезвычайно низкой из-за хорошего разделения слоев: бизнес-логика вообще не была связана с презентацией, так что это был пирог.
Я полагаю, что в текущей экосистеме MVC framework ваш пробег может сильно различаться, поскольку принципы общие, но есть много различий, например, между Zend, Django, RoR и SpringMVC.
Если есть действительно другие хорошие альтернативы этой парадигме… Меня очень интересуют ответы!
Извините за небольшую стену текста!
Комментарии:
1. Я полностью за разделение, но, как указано в подкасте, MVC кажется, что это неправильный подход. «Представление» должно было быть отдельным элементом отображения в пользовательском интерфейсе, а не пользовательским интерфейсом в целом. Кроме того, в Zend, в частности, все это, похоже, слишком зависит от магии — трудно понять, куда дальше перейдет управление потоком программы, не проследив за ним вручную с помощью XDebug или тому подобного. Это может быть просто артефактом интенсивного использования Zend синглетов и реестров.
Ответ №3:
Я думаю, это будет зависеть от того, что вы пытаетесь сделать лично. Magenta довольно успешно использует MVC, и это позволяет довольно легко добавлять новые функции или изменять существующие.
Конечно, если вы пытаетесь сделать что-то довольно простое, переход на архитектуру MVC может быть излишним.
Ответ №4:
Это все предпочтения. Я работал со старыми структурами, такими как XTemplates и Smarty, и теперь перешел к Codeigniter и Kohona. Они мне очень нравятся, и они очень хорошо работают для всего, что я делаю в Интернете. Для телефонных приложений я могу настроить контроллеры для функций, которые необходимы для выполнения извлечения данных. Работает как в мире Linux, так и в мире Windows, для создания ASP.NET Веб-сайты Я не вижу другого способа создания веб-сайтов, кроме использования MVC. Проекты веб-приложений в Visual Studio все еще используются, но я предпочитаю больше этого не делать. Проекты MVC через Visual Studio настолько просты в использовании и настройке. Вы можете щелкнуть правой кнопкой мыши на своих методах контроллера и автоматически создавать представления. В каждой структуре есть хорошее и плохое, но разработчик должен использовать все, что соответствует его потребностям.