MVC - это SEO программирования PHP?
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Есть около миллиона "PHP -каркасов". И большинство из них выставляют себя как следующий шаблон MVC. Хотя приятно преодолеть стиль кодирования Oscommerce (логика обработки в значительной степени смешивается с SQL и HTML), есть, безусловно, проще и легче следить за подходами, чтобы получить конструкцию применения.
Первоначальная концепция MVC была нацелена на приложения GUI. И для GTK/Python кажется возможным следовать за ним соответственно. Но веб -приложения PHP не работают на живых просмотрах (элементы графического интерфейса) и постоянное время выполнения контроллера. Это, безусловно, неправильно, если он просто описывает группировку каталогов Code + или именование класса.
«MVC», кажется, используется как модное слово для PHP Frameworks. И я на самом деле видел, как одна или две зрелые рамки PHP признали это, но в любом случае переопределяли эту фразу, чтобы соответствовать Interna.
Так что это вообще змеиное масло? Почему лучшая терминология не используется, и более разумная концепция для обслуживания PHP распространяется?
Некоторые сложные рассуждения
Почему я подозреваю, что реализации PHP не следуют реальной шаблону MVC:
Модели: Теоретически модели должны быть толстыми и содержать бизнес-логику, а контроллерами должны быть тонкими обработчиками (вход-> выход). В действительности защитники фреймворков PHP мелкий Модели. CI и Symfony, например, приравнивайте модель == orm. Даже HTTP -вход обрабатывается контроллером, не рассматривается как модель.
Просмотры: Обходные пути с дисконтированными Ajax, на веб -страницах не может быть просмотров. PHP Frameworks по -прежнему выкачивают страницы. Интерфейс по-прежнему эффективно следует за обычной моделью HTTP, нет преимуществ в отношении приложений, не связанных с MVC. (И, наконец, ни одна из широко распространенных фреймворков PHP не может фактически выводить в представления GUI вместо HTML. Я видел библиотеку PHP, которая может управлять GTK/Консолью/Интернетом, но фреймворки нет.)
Контроллер: Я не уверен. Контроллеры, вероятно, не должны быть продолжительными и постоянно активными в модели MVC. В контексте PHP Framework они, однако, в основном запрашивают обработчики. На самом деле не что -то, что можно аргументировать, но это просто кажется немного модным.
Будут ли лучшие дескрипторы? Я видел аббревиатуры, такие как PMVC или HMVC. Хотя описания становятся более неоднозначными, может быть, они описывают текущие веб -структуры менее хокки?
Решение
Я думаю, что вы смотрите на это совершенно неправильно. Приложение GUI и веб -страница находятся в мирах, поэтому то же самое определение MVC никогда не будет работать для обоих. MVC - это больше идеал: разделение определенных частей приложения, таких как дисплей и логика.
В PHP (или в Интернете в целом) Вид сама веб -страница: вывод HTML. Это не «живи» в соответствии с вашим определением, но вы просто нажимаете ссылки, чтобы вернуться к контроллеру (то есть другой запрос страницы).
А Контроллер а также Модель где все отличается, как вы объяснили. В PHP модель имеет тенденцию быть слоем данных, взаимодействующим с базой данных и так далее. Но он все еще моделирует ситуацию, и контроллер все еще управляет потоком приложения, если только один раз на страницу загрузку.
Таким образом, название «Модель-видит-контрольер» совершенно логично, хотя и другая реализация в приложениях GUI по сравнению с веб-приложениями.
Другие советы
Поскольку я не знаю о PHP-каркасах, это видно из языкового взгляда на низком уровне.
Модели:
Теоретически модели должны быть толстыми и содержать бизнес -логику
Это полностью, чтобы сделать, я не понимаю, что PHP имеет к этому отношение ...
Модели - это классы данных в PHP, которые, вероятно, могут связаться с базой данных,
Затем вы также можете отправить ту же модель или частичную модель в формате JSON в клиенту.
Я бы не сказал, что бизнес -логика, это больше похоже на логику данных (валидация, взаимодействие с базой данных, импорт/экспорт, ...).
и контроллеры должны быть тонкими обработчиками (вход-> выход)
Ваши классы контроллера взаимодействуют с модельными классами, они действительно тонкие.
Основываясь на выводе, сделайте некоторые вещи с моделями ... и верните модель в клиенте ...
В действительности PHP -структуры защищают мелкие модели. CI и Symfony, например, приравнивайте модель == orm. Даже HTTP -вход обрабатывается контроллером, не рассматривается как модель.
Я не совсем знаю об этих рамках PHP ...
Но вход HTTP должен быть обработан до того, как он достигнет контроллера,
Вы можете легко создать класс, который поворачивает, и публиковать данные в хорошую маршрутизацию и параметры.
Это именно то, что происходит в ASP.NET MVC 2, и в этом нет ничего плохого,
Я не знаю, как это произойдет с PHP, но я думаю, что это будет тесно связано.
Вы даже можете легко превратить данные GET и публиковать данные в модель, модель, возможно, может содержать логику конструктора для этого. Или некоторые отдельные классы могут быть добавлены для этой цели.
Просмотры:
Обходные пути с дисконтированными Ajax, на веб -страницах не может быть просмотров. PHP Frameworks по -прежнему выкачивают страницы.
Я не понимаю, почему это не могло, единственная разница - это протокол, а PHP может вернуть JSON и т. Д.
Страница - это ваше представление, и она может запросить и обновить через AJAX + JSON.
Опять же, я не совсем осознаю эти рамки PHP, но в ASP.NET MVC 2 это работает таким образом.
Интерфейс по-прежнему эффективно следует за обычной моделью HTTP, нет преимуществ в отношении приложений, не связанных с MVC. (И, наконец, ни одна из широко распространенных фреймворков PHP не может фактически выводить в представления GUI вместо HTML. Я видел библиотеку PHP, которая может управлять GTK/Консолью/Интернетом, но фреймворки нет.)
Единственное преимущество, которое вы получаете (и это то же самое с обычными приложениями), - это разделение на модель (data) + view (gui) + контроллер (логика). Подобно, вы не увидите структуру C ++, которая может фактически выводить HTML или JSON вместо представлений GUI.
Контроллер:
Я не уверен. Контроллеры, вероятно, не должны быть продолжительными и постоянно активными в модели MVC. В контексте PHP Framework они, однако, в основном запрашивают обработчики. На самом деле не что -то, что можно аргументировать, но это просто кажется немного модным.
MVC - это программная архитектура/шаблон, где работает контроллер, а как долго нет.
Но веб -приложения PHP не работают на живых просмотрах (элементы графического интерфейса) и постоянное время выполнения контроллера.
Нет, они наверняка делают!
Подумайте о приложениях Ajax, тогда представление спрашивает что -то контроллеру и получает частичное представление, обратно,
Этот представление или данные затем заполняются где -то на странице и, таким образом, вживую обновлены.
Контроллер также настойчив, потому что вы можете использовать файлы cookie/sessions.
«MVC», кажется, используется как модное слово для PHP Frameworks.
MVC - это архитектура программного обеспечения, некоторые фреймворки могут использовать ее как гул, но другие делают это правильно ...
Видеть Список некоторых структур на Википедии.
MVC - это SEO программирования PHP?
MVC и SEO - это две вещи, но да ... MVC становится все более популярным.
На мой взгляд, использование MVC в PHP приводит программистов в Интернет. Легче добраться, например, от Java до PHP, когда вы знаете, как работать с MVC.
