У цьому уроці я розповім Вам, що таке архітектура сайту, яке у неї призначення і якою вона буває.
Архітектура - це базова організація системи, втілена в її компонентах, їхні стосунки між собою і з оточенням, а також принципи, що визначають проектування і розвиток системи [IEEE тисяча чотиреста сімдесят один].
Архітектура програми або комп'ютерної системи - це структура або структури системи, які включають елементи програми, видимі ззовні властивості цих елементів і зв'язки між ними [Басс (Bass)].
Архітектура - це структура організації та пов'язане з нею поводження системи. Архітектуру можна рекурсивно розібрати на частини, які взаємодіють за допомогою інтерфейсів, зв'язку, які з'єднують частини, і умови складання частин. Частини, які взаємодіють через інтерфейси, включають класи, компоненти і підсистеми [UML 1.5].
Архітектура програмного забезпечення системи або набору систем складається з усіх важливих проектних рішень з приводу структур програми і взаємодій між цими структурами, які складають системи. Проектні рішення забезпечують бажаний набір властивостей, які повинна підтримувати система, щоб бути успішною. Проектні рішення надають концептуальну основу для розробки системи, її підтримки та обслуговування [McGovern (Мак-Говерн)].
Наведені в попередньому розділі визначення занадто сухі для їх сприйняття непідготовленим читачем. Постараємося пояснити суть якомога простіше.
Коли програма стає досить великою, програміст розбиває її на кілька файлів. Якщо не замислюватися над виділенням груп схожих функцій і винесенням їх в окремі модулі, таке розбиття принесе мало користі. Код можна буде використовувати повторно, в ньому буде важко орієнтуватися. Програму буде складно розширювати і змінювати.
Таким чином, назріває перше питання: як розбити програму на файли. Файлова архітектура програми - це один з аспектів її структури.
Виділяючи модулі системи, необхідно розуміти, в якому відношенні один до одного вони будуть знаходитися. Наприклад, модулі доступу до бази даних та обробки графічних зображень навряд чи повинні знати що-небудь про існування один одного. Але модуль призначеного для користувача інтерфейсу буде знати про них обох (а вони про нього не будуть).
Відносини між компонентами системи також визначаються її архітектурою.
В цілому, всі значущі рішення, спрямовані на організацію програми, а не на проблеми, які вирішуються з її допомогою, можна віднести до архітектури.
При проектуванні модулів (вибору груп функцій і розподілу їх по файлах в разі процедурного підходу) важливо виділяти абстракції і намагатися їх розкласти по декількох рівнях.
Модулі низького рівня максимально автономні, вони не залежать від інших частин програми. Добре спроектовані модулі ізолюють "зовнішній світ" від тонкощів вирішення поставленого перед ними завдання. Зухвала сторона знає лише інтерфейс модуля (зовнішні функції), внутрішня частина для неї закрита.
Розглянемо як приклад галерею фотографій. Інформація про зображення і користувачів зберігається в БД, призначений для користувача інтерфейс розділений на клієнтську частину та панель адміністратора.
Структура програми могла б бути такою, як на малюнку нижче:
У цьому прикладі простежуються три рівні абстракції.
У будь-якій програмі, призначеної для використання людиною, можна виділити, принаймні, два рівня: призначений для користувача інтерфейс і модель. Модуль призначеного для користувача інтерфейсу призначений для подання і візуалізації даних, обробки реакції користувача. Модель містить в собі логіку розв'язуваної задачі і не повинна ні в якій мірі бути залежною від способу відображення даних. Модель повинна бути легко переносимо між різними типами користувальницького інтерфейсу.
Зараз популярний шаблон проектування MVC. Він служить для відділення логіки додатка від призначеного для користувача інтерфейсу. Але спочатку з'ясуємо, що таке шаблон проектування.
Це набір типових рішень проектування, каркас архітектури або її фрагмента. Якщо бібліотека - це пакет повторно використовуваного коду, то шаблон проектування - це пакет повторно використовуваних рішень.
Що ж пропонує нам MVC для відділення логіки додатка від призначеного для користувача інтерфейсу?
Шаблон MVC дозволяє розділити дані, подання та обробку дій користувача на три окремих компоненти:
- Модель (Model). Модель надає дані (зазвичай для Уявлення), а також реагує на запити (зазвичай від Контролера), змінюючи свій стан;
- Подання (View). Відповідає за відображення інформації (призначений для користувача інтерфейс);
- Контролер (Controller). Інтерпретує дані, введені користувачем, і інформує модель і уявлення про необхідність відповідної реакції.
На малюнку нижче показані відносини між компонентами каркаса. Проілюструємо малюнок невеликим прикладом.
Уявіть форму, де можна ввести текст, натиснути кнопку Edit і отримати його транслітерацію:
Повторимо кроки, зображені на схемі:
- Користувач натискає кнопку Edit, при цьому Подання (View) посилає повідомлення Контролеру (Controller): "Команда: edit"
- Контролер приймає повідомлення і звертається до Моделі (Model), викликаючи метод Edit ().
- В результаті модель змінює свій стан (запомненний в ній транслітерований текст) і сповіщає про це уявлення: "Подія: changed".
- Подання приймає сигнал і звертається до моделі за новим значенням результату, викликаючи її метод Get ().
Реалізація MVC припускає об'єктно-орієнтований підхід (ООП). Однак шаблон проектування - це всього лише набір рішень. Адаптуємо їх для PHP без застосування ООП. Спрощення робиться для того, щоб сконцентруватися на суті поділу логіки, а також для того, щоб матеріал зміг застосувати читач, не знайомий з ООП.
Також є можливість завантажувати фотографії на сервер. Додатково реалізуємо підтримку типів візуалізації, щоб оцінити гнучкість каркаса.
На сайті будуть дві точки входу.
Як Моделі виступатиме модуль, що забезпечує роботу зі сховищем зображень. Назвемо його gallery.php і помістимо в папку model.
У ролі Уявлення виступатимуть HTML-шаблони, вони будуть перебувати в папці templates. Що таке шаблони і для чого вони потрібні - буде видно далі.
Виходить наступна структура сайту:
Файлова структура розділена двома горизонтальними рисами, що утворюють три секції. Файли верхньої секції відносяться до Моделі, файли середньої секції - до Поданню, файли нижньої секції - до Контролеру.
Почнемо з реалізації Моделі. У коді нижче наведено в повному обсязі для мінімізації і кращої наочності прикладу.
Ми визначили лише інтерфейс Моделі, залишивши реалізацію пропущеної. Однак для прикладу реалізації каркаса MVC вона зовсім і не потрібна.
Тепер розглянемо шаблони. Почнемо з загального каркаса сторінки:
Вас не повинно бентежити, що в шаблоні використовуються незрозуміло звідки взялися змінні $ title і $ content. Їх підставить Контролер. Але про це пізніше.
- це скорочений варіант запису .
Його зручно використовувати в шаблонах. Також в шаблонах зручніше використовувати альтернативні варіанти запису конструкцій if-else. foreach. for. while. Виглядають вони так:
Решта шаблони будуть підставлятися в main.php таким чином:
У прикладах нижче, наведено їх код:
І, нарешті, зберемо всі разом, описавши наші два Контролера. Їх завдання полягає в обробці запиту, виборі шаблону і підстановці потрібних шаблоном даних. Дані беруться, як правило, з моделі.
Контролер галереї завантажує фотографію, якщо користувач відправив файл. Інакше він витягує з моделі список фотографій, вибирає потрібний шаблон (в залежності від бажання користувача) і виводить цей шаблон, передавши йому список фотографій:
Намагайтеся приділяти достатньо уваги розробці архітектури вашого застосування. Якщо спочатку створити міцний і розширюваний каркас, зусилля окупляться сторицею.
Для реалізації моделі MVC краще вибрати об'єктно-орієнтований підхід.
Існує безліч готових рішень каркаса, наприклад в Zend Framework. Однак інформації, викладеної в поточному уроці, досить для того, щоб зрозуміти архітектурні рішення MVC і почати їх використовувати вже зараз.