MVC - это просто SEO программирование на PHP?

9

Есть около миллиарда "PHP-фреймворков". И большинство из них выставляют себя в соответствии с моделью MVC. Несмотря на то, что можно преодолеть стиль кодирования osCommerce (логика обработки, сильно смешанная с SQL и HTML), безусловно, существуют более простые и легкие в использовании подходы для получения поддерживаемого дизайна приложения.

Первоначальная концепция MVC была ориентирована на приложения с графическим интерфейсом. И для Gtk / Python представляется целесообразным следовать ему соответствующим образом. Но веб-приложения PHP не работают с живыми представлениями (элементами GUI) и постоянным временем выполнения контроллера. Это, безусловно, неправильно, если он просто описывает используемый код + группирование каталогов или именование классов.

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

Некоторые подробные рассуждения

Почему я подозреваю, что реализации PHP не следуют настоящему шаблону MVC:

Модели : теоретически, модели должны быть толстыми и содержать бизнес-логику, а контроллеры должны быть тонкими обработчиками (input-> output). В действительности фреймворки PHP поддерживают мелкие модели. CI и Symfony, например, приравнивают Model == ORM. Даже HTTP-ввод обрабатывается контроллером, а не моделью.

Просмотры : обходные пути со скидкой AJAX, на веб-страницах не может быть просмотров. Фреймворки PHP по-прежнему выкачивают страницы. Интерфейс по-прежнему эффективно следует обычной модели HTTP, и нет никаких преимуществ перед приложениями, отличными от MVC. (И, наконец, ни одна из широко распространенных фреймворков php фактически не может выводить в представления GUI вместо HTML. Я видел библиотеку PHP, которая может работать с Gtk / Console / Web, но фреймворки этого не делают.)

Контролер : я не уверен. Контроллеры, вероятно, не должны быть долговременными и постоянно активными в модели MVC. В контексте PHP среды они, однако, в основном обработчики запросов. Не совсем то, о чем можно спорить, но это звучит слегка модно.

Будут ли лучшие дескрипторы? Я видел такие сокращения, как PMVC или HMVC. Хотя описания там становятся более двусмысленными, возможно, они описали бы текущие веб-фреймворки менее наглядно?

марио
источник
Итак, в заключение: фреймворки PHP реализуют концепцию, аналогичную оригинальному MVC. Я думаю, что это лучше всего прибить здесь: stackoverflow.com/questions/1549857/simple-php-mvc-framework/…
Марио
Я был удивлен, прочитав, что "большинство PHP-фреймворков используют Views как просто страницы". Во всех PHP-фреймворках, которые я использовал, View может быть любым, в основном это просто HTML-шаблон. Таким образом, это может быть текстовое поле, боковая панель, панель навигации, блок статического текста или даже макет страницы. Я не могу представить ни одного фреймворка, который бы позволял вам встраивать представления в представления, позволяя вам делать практически все, пока ваша фактическая бизнес-логика / обработка выполняется в контроллере заранее.
Lotus Notes
Модель (не множественное число) является слоем . Это не один файл или класс. Это коллекция объектов домена, картографов данных и сервисов. Прочитайте это .
Джеймс
3
... SEO? «Поисковая оптимизация»?
Изката

Ответы:

12

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

В PHP (или в Интернете в целом) View - это сама веб-страница: вывод HTML. Он не «живой», согласно вашему определению, но вы просто нажимаете на ссылки, чтобы вернуться к контроллеру (то есть к другому запросу страницы).

Контроллер и модель , где вещи отличаются, как вы объяснили. В PHP модель, как правило, представляет собой слой данных, взаимодействующий с базой данных и так далее. Но он все еще моделирует ситуацию, и контроллер все еще контролирует поток приложения, хотя бы один раз на загрузку страницы.

Таким образом, название «Model-View-Controller» совершенно логично, хотя и отличается от реализации в приложениях с графическим интерфейсом и веб-приложениях.

DisgruntledGoat
источник
Я не ссорюсь с абстрактной концепцией MVC. Я возражаю, что PHP-фреймворки нечестны в том, что на самом деле просто реализуют Passive-MVC. Даже шаблон «Модель-Представление-Презентатор» является более реалистичным описанием. Но, конечно, условия должны быть изменены, когда вы применяете их к другому домену. Оригинальный вопрос; может ли термин изгиб сделать это модным словом?
Марио
3

Поскольку я не знаю фреймворков PHP, это видно из низкоуровневого языкового представления.

Модели:

в теории, модели должны быть толстыми и содержать бизнес-логику

Это все, что нужно сделать, я не вижу, что PHP должен делать с этим ...

Модели - это классы данных в PHP, которые могут взаимодействовать с базой данных,
тогда вы также можете отправить клиенту ту же модель или частичную модель в формате JSON.

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

а контроллеры должны быть тонкими обработчиками (input-> output)

Ваши классы Controller взаимодействуют с классами Model, они действительно тонкие.

Основываясь на результатах, сделайте некоторые вещи с Моделями ... И верните ModelView клиенту ...

В действительности фреймворки PHP поддерживают мелкие модели. CI и Symfony, например, приравнивают Model == ORM. Даже HTTP-ввод обрабатывается контроллером, а не моделью.

Я не очень осведомлен об этих PHP фреймворках ...

Но ввод HTTP должен обрабатываться до того, как он достигнет контроллера,
вы можете легко создать класс, который превращает данные GET и POST в хорошую маршрутизацию и параметры.

Это именно то, что происходит в ASP.NET MVC 2, и в этом нет ничего плохого,
я не знаю, как это произойдет с PHP, но я думаю, что это будет тесно связано.

Вы даже можете легко превратить данные GET и POST в модель, модель может содержать логику конструктора для этого. Или несколько отдельных классов могут быть добавлены для этой цели.


Взгляды:

обходные пути со скидкой AJAX, не может быть просмотров на веб-страницах. Фреймворки PHP по-прежнему выкачивают страницы

Я не понимаю, почему это невозможно, единственное отличие - протокол и PHP могут возвращать JSON и т. Д.

Страница - это ваш вид, и она может запрашивать и обновлять через AJAX + JSON.
Опять же, я не очень осведомлен об этих PHP-фреймворках, но в ASP.NET MVC 2 это работает именно так.

Интерфейс по-прежнему эффективно следует обычной модели HTTP, и нет никаких преимуществ перед приложениями, отличными от MVC. (И, наконец, ни одна из широко распространенных фреймворков php фактически не может выводить в представления GUI вместо HTML. Я видел библиотеку PHP, которая может работать с Gtk / Console / Web, но фреймворки этого не делают.)

Единственное преимущество, которое вы получаете (и то же самое с обычными приложениями) - это разделение на Модель (Данные) + Представление (GUI) + Контроллер (Логика). Похоже, вы не увидите платформу C ++, которая фактически может выводить в HTML или JSON вместо представлений GUI.


контроллер:

Я не уверен Контроллеры, вероятно, не должны быть долговременными и постоянно активными в модели MVC. В контексте PHP среды они, однако, в основном обработчики запросов. Не совсем то, о чем можно спорить, но это звучит слегка модно.

MVC - это программная архитектура / шаблон, где контроллер работает и как долго не работает.

Тамара Вийсман
источник
1

Но веб-приложения PHP не работают с живыми представлениями (элементами GUI) и постоянным временем выполнения контроллера.

Нет, они уверены!

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

Контроллер также постоянен, потому что вы можете использовать куки / сессии.

«MVC», кажется, используется как модное слово для фреймворков PHP.

MVC - это программная архитектура, некоторые фреймворки могут использовать ее как шум, но другие делают это правильно ...
Смотрите список некоторых фреймворков в Википедии .

MVC - это просто SEO php-программирования?

MVC и SEO - это две разные вещи, но да ... MVC становится все более популярным.

Тамара Вийсман
источник
1
Конечно, элементы пользовательского интерфейса AJAX сближают его, но это объективное решение. И это все еще кажется изгибанием определения. (Между прочим, я знаю о Cappucino.org и других реальных инструментальных средствах, но имел в виду основную часть PHP-фреймворков.)
Марио,
Тогда это не будет обходным решением, вы также можете считать Qt и другие фреймворки обходными путями ... Тогда есть только накладные расходы на передачу данных между сервером и клиентом, а с текущими скоростями и задержками соединения это даже немного больше. Я не вижу, как это изгибает определение: шаблон изолирует доменную логику (логику приложения для пользователя) от ввода и представления (UI), позволяя независимую разработку, тестирование и обслуживание каждого из них.
Тамара Вийсман
1
Я понимаю что ты имеешь ввиду. Если вы интерпретируете PHP как сервер приложений и AJAX как механизм RPC между логикой и пользовательским интерфейсом, то да. Однако я бы все еще назвал это обходным решением для HTTP. OTOH не уверен, имеет ли это отношение к конфессии MVC. Я думаю, что на самом деле возражаю против того, что только "" "MVC" "" предоставляет отзывчивые и интерактивные веб-интерфейсы, которые вы описываете.
Марио
-1

По моему мнению, использование MVC в php приводит программистов в сеть. Например, легче перейти с Java на PHP, если вы знаете, как работать с MVC.

baklap
источник
+1 Но это просто терминологическое преимущество или есть PHP-фреймворки, близкие к реализации Java. (И косвенно, вы говорите о Java GUI или Web / Struts?)
Mario
Я не знаю точно, но я использую Zend Framework, и я думаю, что то же самое с другими средами MVC: очень важно знать, что делать в вашей модели, представлении и контроллере, и, таким образом, разрыв между миром программирования и межсетевым взаимодействием Мир закрыт. Может быть, межличностный возраст закончился, и мне бы очень хотелось это увидеть. Это слишком глючит.
Баклап