Чи MVC - це просто SEO програмування PHP?

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

Оригінальна концепція MVC була орієнтована на програми GUI. А для Gtk / Python здається, що це можливо дотримуватися відповідно. Але веб-додатки PHP не працюють на режимах перегляду в реальному часі (елементи графічного інтерфейсу) та постійному режимі роботи контролера. Це, безумовно, помилково, якщо він просто описує використаний код + групування каталогів або назви класів.

Здається, "MVC" використовується як модна мова для фреймворків PHP. І я насправді бачив, як одна-дві зрілі рамки PHP це визнають, але переосмислюючи фразу все одно, щоб вона відповідала інтерні.
Так це взагалі зміїна олія? Чому не використовується краща термінологія, а більш розумна концепція пропагандированного PHP?

Деякі детальні міркування

Чому я підозрюю, що реалізація PHP не відповідає реальній схемі MVC:

Моделі : теоретично, моделі повинні бути жирними і містити ділову логіку, а контролери - тонкі обробники (введення> вихід). Насправді рамки PHP виступають неглибоко моделі. CI і Symfony, наприклад, прирівнюють Модель == ORM. Навіть вхід HTTP обробляється контролером, не розглядається як модель.

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

Контролер : Я не впевнений. Контролерам, напевно, не потрібно бути тривалими та наполегливо активними у моделі MVC. Однак в контексті PHP вони, в основному, обробляють запити. Насправді не про що можна аргументувати, але це просто трохи химерно.

Чи будуть кращі дескриптори? Я бачив такі акроніми, як PMVC або HMVC, кинуті навколо. Хоча описи там стають більш амбітними, можливо, вони описують поточні веб-рамки менш хокейними?

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

У PHP (або в Інтернеті взагалі), View - це сама веб-сторінка: вихід HTML. Це не "живе" за вашим визначенням, але ви просто натискаєте посилання, щоб повернутися до контролера (тобто іншого запиту на сторінку).

Контролер і модель , де речі відрізняються, як ви пояснили. У PHP модель, як правило, є рівнем даних, взаємодіючи з базою даних тощо. Але це все ще моделює ситуацію, і контролер все ще контролює потік додатків, хоч раз на завантаження сторінки.

Тож назва "Model-View-Controller" є цілком логічною, хоча і різною реалізацією в додатках GUI та веб-програмах.

Оскільки я не знаю про рамки PHP, це видно з мовного погляду на низькому рівні.

Моделі:

теоретично Моделі повинні бути жирними і містити ділову логіку

Це абсолютно важливо, я не бачу, що PHP має до цього відношення ...

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

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

і контролери повинні бути тонкими обробниками (вхід-> вихід)

Ваші класи контролерів взаємодіють із класами Model, вони справді тонкі.

Виходячи з результатів, зробіть деякі речі з Моделями ... І поверніть ModelView клієнту ...

Насправді рамки PHP пропонують мілкі моделі. CI і Symfony, наприклад, прирівнюють Модель == 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 Views замість HTML. Я бачив бібліотеку PHP, яка може працювати з Gtk / Console / Web, але фреймворки це не роблять.)

Єдина перевага, яку ви отримуєте (і те ж саме у звичайних додатках) - це розділення на Model (Data) + View (GUI) + Controller (Logic). Аналогічно, ви не побачите фреймворк C ++, який фактично може виводити HTML або JSON замість GUI Views.

Контролер:

Я не впевнений. Контролерам, напевно, не потрібно бути тривалими та наполегливо активними у моделі MVC. Однак в контексті PHP вони, в основному, обробляють запити. Насправді не про що можна аргументувати, але це просто трохи химерно.

MVC - це програмна архітектура / схема, де контролер працює і наскільки довго не відповідає.

Але веб-додатки PHP не працюють на режимах перегляду в реальному часі (елементи графічного інтерфейсу) та постійному режимі роботи контролера.

Ні, вони впевнені!

Подумайте про додатки AJAX, тоді перегляд запитує щось у контролера і отримує частковий перегляд назад,
цей вигляд або дані потім заповнюються десь на сторінці і таким чином оновлюються.

Контролер також є стійким, оскільки ви можете використовувати файли cookie / сеанси.

Здається, "MVC" використовується як модна мова для фреймворків PHP.

MVC - це архітектура програмного забезпечення, деякі фреймворки можуть використовувати його як шум, але інші роблять це правильно ...
Дивіться список деяких фреймворків у Вікіпедії .

MVC - це просто SEO програмування PHP?

MVC та SEO - це дві речі, але так ... MVC стає все популярнішим.

На мою думку, використання MVC у php приносить програмістів в Інтернет. Простіше дістатися, наприклад, від Java до PHP, коли ти знаєш, як працювати з MVC.