Архитектура больше подходит для веб-приложений, чем MVC?

Я изучил Zend и его структуру приложений MVC для своей новой работы и обнаружил, что работа с ней просто беспокоила меня по причинам, на которые я не мог положиться. Затем в ходе моих исследований я столкнулся с такими статьями, как MVC: No Silver Bullet и этот подкаст на тему MVC и веб-приложений. Парень в подкасте сделал очень хороший пример против MVC в качестве архитектуры веб-приложений и прибил много того, что меня било по голове.

Однако вопрос остается, если MVC на самом деле не подходит для веб-приложений, что это такое?

Все зависит от стиля кодирования. Вот секрет: невозможно написать классический MVC в PHP.

Любая структура, которая утверждает, что вы можете, врет вам. Реальность такова, что сами структуры не могут даже реализовать MVC – ваш код может. Наверное, это не такой хороший маркетинговый шаг.

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

В веб-разработке у вас есть еще 4 других MVC-решения:

  • Model2 MVC : View запрашивает данные из модели, а затем решает, как ее отобразить и какие шаблоны использовать. Контроллер отвечает за изменение состояния как View, так и модели.

  • MVVM : контроллер переопределяется для ViewModel, который отвечает за перевод ожиданий View и логики моделей. Просмотр запросов данных от контроллера, который переводит запрос, чтобы Модель могла его понять.

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

  • MVP (какие фрэш-структуры называют «MVC»): Presenter запрашивает информацию из модели, собирает ее, изменяет ее и передает ее пассивному представлению.

    Чтобы изучить этот шаблон, я бы рекомендовал вам начать с этой публикации . Это объяснит это подробно.

  • HMVC (или PAC): отличается от Model2 способностью контроллера выполнять субконтроллеры. Каждый из них имеет собственную триаду M, V и C. Вы получаете модульность и ремонтопригодность, но платите с некоторым ударом по производительности.

Так или иначе. Суть в том, что вы на самом деле не использовали MVC.

Но если вы устали от всех MVC-подобных структур, вы можете посмотреть:

  • архитектуры, управляемые событиями
  • Архитектура n-уровня

И тогда всегда существует парадигма DCI , но она имеет некоторые проблемы при применении к PHP (вы не можете бросать класс в PHP .. не без уродливых хаков).

По моему опыту, преимущества, которые вы получаете от архитектуры MVC, намного превосходят его затраты и очевидные накладные расходы при разработке для Интернета.

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

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

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

Если есть действительно другие хорошие альтернативы этой парадигме там … Я очень заинтересован в ответах!

Извините за небольшую стену текста!

Я думаю, что это будет зависеть от того, что вы пытаетесь сделать лично. Magenta использует MVC довольно успешно, и это позволяет легко добавлять новые функции или изменять существующие.

Конечно, если вы пытаетесь сделать что-то довольно простое, переход с архитектурой MVC может быть излишним.

Это все предпочтение. Я работал со старыми структурами, такими как XTemplates и Smarty, и теперь перешел к Codeigniter и Kohona. Мне они очень нравятся, и они отлично работают для всего, что я делаю в Интернете. Для приложений для работы с телефоном я могу настроить контроллеры для функций, которые необходимы для выполнения этих операций. Работая как в мире Linux, так и в Windows World, для создания веб-сайтов ASP.NET я не вижу другого способа создания сайтов рядом с использованием MVC. Проекты веб-приложений в Visual Studio все еще используются, но я больше не хочу этого делать. Проекты MVC через Visual Studio настолько просты в использовании и настройке. Вы можете щелкнуть правой кнопкой мыши по вашим методам контроллера и автоматически создать представления. В каждой структуре есть хорошо и плохо, но разработчик должен использовать все, что соответствует их потребностям.