Реальність
Часто веб-додаток є процесом, в якому час – критичний фактор. Оскільки кодінг зазвичай є останнім кроком, все з'єднується разом і виявляються головні помилки.
«Зроби його таким, щоб воно однаково виглядало у всіх браузерах працювало краще за штучний інтелект, який будь-коли був задуманий і вміло літати», - зазвичай ми чуємо дещо на зразок цього.
Працюючи в умовах обмеженої кількості часу, розробники часто удаються до швидких виправлень. До кінця проекту вони опиняються в купі коду і це не лише із-за змін в останню хвилину.
«Ну і що, якщо сайт працює добре, ніхто не скаржиться і клієнт схвалив його?» - можете запитати ви.
Це відношення, з яким я стикався багато разів. Часто це закінчується проблемами на подальшому етапі будь то розширення сайту, новий вигляд або зміна сервера.

Теорія
Ось де MVC приходить на допомогу. Це в цілому спроба структурувати веб-додаток в три компоненти:

• Модель в цілому розуміється як компонент адміністрування даних. У більшості веб-проектів це участь даних в реляційних системах баз даних, але воно може включати інші стійкі бізнес-об'єкти, наприклад, Enterprise Java Beans. Модель пасивна і нічого не запускає. Дані викликаються незалежно від їх вигляду (view); модель не знає нічого про представлення даних. Модель може працювати з одним (стосунки 1:1) або декількома Видами і Контроллерами (стосунки типу 1:n).


• Вигляд описує візуальне представлення Моделі. В разі багатьох динамічних веб-сайтів, ви можете представити один або два Види в одній і тій же Моделі: у випадку з цією статтею, одним Виглядом буде публічний – той, в якому ви бачите статтю зараз, і іншим буде той у якому я можу її створювати і редагувати. Звичайно, є багато інших можливостей: користувачі різних рівнів, кожен з певним набором прав; різні відображення одного і того ж сайту для звичайних користувачів; висока контрастність для зручності читання; Вигляд для друку без навігації і шапки і так далі.


• Контроллер реалізує всю логіку додатку. Це активний компонент. Додаток отримує запити, передає їх відповідним підкомпонентам системи і, можливо, відправляє відповіді назад користувачеві. Контроллер проводить різні маніпуляції над Моделлю для виконання дій користувача.
  Дедалі краще. Тепер, коли теорія зрозуміла, ми можемо поглянути, як це використовується в процесі веб-розробки.

Чи дійсно мені це потрібно? Це досить чутлива тема. При її дослідженні я знайшов декілька підходів, більшість з яких десь в трикутнику з рішучих сердитих і нахабних. Я хочу відзначити найочевидніші причини використовувати його, сподіваюся, що не наступатиму нікому на мозоль:

• Співвіднесіть розумовий патерн: внести свій код до програмного патерну досить складно, коли ви намагаєтеся робити це під час програмування, але ідея полягає в тому, щоб спочатку структурувати код в голові або на аркуші паперу або, для масштабніших проектів – за допомогою інструментів CASE. З документованою структурою, ваш код стає більш керованим, і кількість людей, які хочуть бачити вас такими, що горить в пеклі (можливо, навіть ви самі раз в 1-2 роки), зменшується. Кожен розробник, який розуміє MVC, швидко знайде шлях у вашому коді, і ви обидва працюватимете на одній хвилі бо ви слідуєте одному зразку, в коді і думках.


• Можливість повторного використання. Це має місце у будь-якому вигляді модулярізації, і це аргумент, який не варто ігнорувати: як тільки ви продумали і склали свою модель, ви можете її знову використовувати багато разів з мінімальними змінами або взагалі без них.


• Розширюваність: із строгою модулярізацією у вас є чітко певне поле для роботи, коли доходить справа до змін вигляду, функціональності або зберігання даних. Залежно від потреб ваших веб-додатків і реальної ситуації, ви можете вирішити, яка частина вимагає поліпшення.

Практика
Я виявив, що Jakarta Struts – це дійсно хороше Java-рішення, і недавно журнал PHP Architect запропонував безкоштовно завантажити їх травневий випуск 2003 року, який містить хорошу вступну статтю з вирішенням, заснованому на шаблонах Smarty. На сайті Tony Marston'а серед тонн інформації і зразків дизайну можна знайти розширене вирішення, яке включає трирівневу архітектуру, теж засновану на PHP.
Я міг би зупинитись на цьому і залишити вас з одним з прикладів, але дозвольте мені сказати наступне: я вважаю що розмір проекту і можливість зміни або оновлення окремих компонентів повинно грати таку ж важливу роль, як і можливість повторного використання коду.
З часом ми з Паскалем досягли слабенького фреймворку з PHP класів який зберіг купу часу під час створення проектів середньої масштабності, завдяки можливості повторного використання їх підкомпонентів.
Види встановлені за допомогою CSS і (Х) HTML, стилів XSL, що згенерувано шаблонами.
У внутрішньому (backend) PHP, класи структуровані по їх функціональності. Клас db управляє роботою всіх баз даних на найнижчих рівнях: для зміни бази даних замініть його або змініть конфігурацію. Цей клас представляє Модель. Ваш сервер був зламаний і вам потрібно посилатися на резервний db-сервер? Це робиться за 10 секунд.
Базовий клас, тим часом, несе в собі всі допоміжні функції, які використовується в більшості проектів, наприклад, як рядок і операції з датою. Це розширення класу page, яке слід додавати в проект насамперед. Ми потурбувалися про структуру сайту (звичайне риття бази даних тим або іншим способом, як дерево або плоску модель сторінки), функції для breadcrumbs і навігації отримують дані і повертають XML, глобальні елементи сайту отримують свої дані. Але не лише це: тут також можна знайти все що загалом називається бізнес логіка, обчислення, автоматизація роботи і тому подібне. Клас може бути розширений для сторінок спеціального призначення, щоб зберігати їх красивими і акуратними. Я їх групую як Контроллер. Вони отримують всі запити, приписують значення Моделі (клас db) щоб доставити XML, щоб видозмінитися Виглядом (View) за допомогою XSL.
Але це не зовсім точно підходить до MVC патерну: жоден SQL не буде знайдений в класі сторінки. Звичайний прийом в цьому випадку – встановити клас для кожної таблиці, яка містить всі запити. У такому разі, ви знаєте, де знайти ваші SQL і до яких класів звертатися, щоб зробити зміни в db-сервері. Як альтернатива, ви можете розширити db-класс і озаглавити його функціями більш високого рівня, які складуть для вас SQL. З одного боку, вам необхідно змінювати лише один файл (на відміну від того, коли у нас файл для кожної таблиці); з іншого боку – рішення розвиваються досить складно, тим самим ускладнюючи роботу наступному розробникові. До того ж, він може бути дуже специфічним для одного сайту, і таким чином, не дуже портативним.
Встановивши ці класи як стартовий пакет, ви отримаєте неймовірно швидкі результати – і робота в frontend/backend команді стане задоволенням. Просто заповніть абстрактний файл XML всіма даними, які вам необхідні і його можна буде обробляти в двох направленнях: xsl/html/css з одного боку і php/db – з іншого.
Для деяких випадків я залишаю табличні класи як набір для проектів середнього розміру. У інших випадках я або використовую реляційні бази даних (зазвичай ефективно) і спрограмованний в чистому Sql-92 – хоча це стає незручним, і я не впевнений, чи слідують звичайні бази даних цьому стандарту – або ж я переконуюся, що додаток бази даних залишався без змін впродовж всього існування сайту.
Як і з більшістю речей в сучасному цифровому світі, сайти постійно змінюються, але код навряд чи витримує більше трьох років. Ваш бюджет, тимчасові рамки і призначення сайту, визначатимуть наскільки ви хочете використовувати MVC. Але це завжди гідно роздумів.

Оригінал: MVC in smaller web applications