Framework-системи
Що таке framework-система? Навіщо вона Вам потрібна? У чому вона Вам може допомогти? А в чому ні? У цьому документі я спробую дати відповіді на ці питання.
Інтернет технології за останні десять років зробили дуже великий крок вперед, ставши полігоном для ведення бізнесу та електронної комерції. Розвиток глобальної мережі спричинило за собою розвиток інтернет-додатків. Якщо раніше сайти були не більше ніж «оголошеннями на заборі», то тепер це повноцінні програми, здатні виконувати завдання по автоматизації збору даних, обробки даних та надання інформації.
Перед сучасними web-розробниками постає дуже широкий спектр завдань. Це ефективна робота з реляційними базами даних, зберігання і обробка даних у форматі XML, побудова гнучких систем відображення інформації та багато іншого. Така множина завдань робить старі методи розробки додатків вкрай неефективними. Це призводить до думки про необхідність наявності спеціального інструментарію для web-розробника, який допоможе йому у вирішенні часто виникаючих проблем і завдань.
Що таке framework?
Коли людина вирішує якесь завдання багато разів поспіль, він вчиться вирішувати її швидко і ефективно! З точки зору web-програмування, framework-система (CMF-система) це платформа, що дозволяє вирішувати завдання, які постійно виникають при створенні інтернет-додатків. Не варто думати, що CMF-система - це просто набір модулів для вирішення різнотипних завдань, яких в Інтернеті безліч.
Framework-система це щось більше. Це:
• Термінологія, яка дозволяє розробникам говорити лаконічно про дуже складні речі;
• Набір архітектурних стандартів, які система накладає на інтернет-додатки. Це знімає з розробників необхідність придумувати все з нуля і дозволяє більш ефективно використовувати код повторно;
• Модулі для вирішення завдань «першої необхідності», що дозволяють почати розробку з порожнього місця, не винаходячи нічого свого.
Framework-система для web-розробника відіграє таку ж роль, як саквояж з інструментами для монтажника. Навіть якщо монтажник зможе виконати свою роботу без свого саквояжа, він витратить більше часу, а якість виконаної роботи буде на порядок нижче. Аналогічна ситуація спостерігається в процесі створення інтернет-додатків.
CMF і CMS
Розглядаючи поняття framework-системи, не можна обійти стороною, поняття системи управління контентом. Дуже часто поняття CMF (Content Management Framework) плутають з поняттям CMS (Content Management System). Це невірно, тому що це принципово різні речі.
CMF-системи не можна порівнювати з CMS-системами! Це головне правило, яке дуже часто порушують розробники при обговоренні питань пов'язаних з розробкою та використанням CMF-систем. CMF і CMS різні поняття, незважаючи на їх схожість.
CMS-система - це набір модулів для швидкого створення сайтів. На відміну від CMF, CMS-система - це є завершений продукт, який орієнтований, в першу чергу, не на програмістів, а на користувачів не знайомих з премудростями створення інтернет-додатків. CMS-система (дуже часто її називають «движок сайту») дозволяє за лічені години створити сайт або портал який складається з обмеженого набору готових модулів (новини, гостьова книга, форум). В більшості своїй, CMS-системи створюються без урахування їх подальшого зростання. Підсумок - відсутність жорсткої внутрішньої архітектури системи. Це істотно ускладнює процес супроводження проекту.
Якщо вам достатньо можливостей CMS-системи, то, швидше за все, Ви будете задоволені. Однак якщо перед Вами постане питання про зміну дизайну або розширення можливостей програми, то, в більшості випадків, Вам доведеться вдатися за допомогою до кваліфікованих програмістів. І, можливо, навіть їм буде не просто розібратися в цій CMS-системі. Прочитавши наступний параграф, Ви зрозумієте, чому в цьому абзаці так багато «можливо» і «швидше за все».
Вищесказане відноситься до «чистих» CMS-систем. Тобто до CMS-систем, які написані з нуля на порожньому місці. На щастя, ніхто не заважає використовувати вигоди обох типів систем. Останнім часом в Інтернеті почали з'являтися CMF / CMS-системи. Ці системи являють собою CMS-систему, створену на фундаменті framework'а. Вигоди очевидні. Детермінована внутрішня архітектура, яка в більшості випадків документована і розвинені механізми абстракції, які не залежать від CMS-утворюючих модулів. Супроводжувати проект, створений на основі CMF / CMS-системи, на порядок простіше, ніж проект, створений на основі «чистої» CMS-системи. Це пояснюється тим, що в першому випадку, при створенні CMS-системи, програмістам доводиться виконувати ряд вимог, які диктує framework. Завдяки цьому CMS-система набуває яскраво виражену архітектуру, як і всі додатки створюються за допомогою CMF-системи.
Якщо CMS-система являє собою закінчений продукт, то CMF-система - це набір інструментів, за допомогою яких, можна створити абсолютно будь-який продукт, зокрема і CMS-систему. Так як framework-система - це набір інструментів, то для її використання потрібні програмісти, які можуть з цими інструментами працювати. З цим пов'язаний ще один момент, характерний для CMF - навчання персоналу для роботи з CMF-системою.
Продукти CMF-системи (додатки, написані на її основі) відрізняються індивідуальністю та високим рівнем адаптації до конкретної ситуації, тому що вони є програмними рішеннями, призначеними для вирішення конкретного кола завдань у конкретному контексті. За допомогою CMF можна створювати будь-які інтернет-додатки, починаючи гостьовими книгами, закінчуючи інтернет-магазинами і веб-сервісами.
Маючи фахівців, які знають архітектуру використовуваної CMF-системи, стає можливим, відносно легко, розширювати можливості системи, проводити аудити безпеки і т.д.
Архітектура CMF-системи
У попередніх розділах вже було сказано дуже багато про архітектуру. Вам може здатися, що архітектурні стандарти абсолютно не потрібні. Але необхідно розуміти, що подібна «диктатура» не має на меті обмеження програміста у прийнятті рішень. Навпаки це зроблено для забезпечення максимальної гнучкості архітектури та можливості її безболісної зміни. Безумовно, в жертву таким якостям доводиться приносити простоту та прозорість системи.
Питання архітектури дуже складні за своєю суттю, і навіть багато фахівців не можуть сказати за п'ять хвилин нічого зрозумілого із приводу якихось конкретних рішень. Але, незважаючи на таку велику контекстну залежність архітектури від типу додатка, існують добре вивчені і перевірені варіанти вирішення архітектурних проблем. Ці варіанти рішення носять назву «шаблони проектування» (Design Patterns). У тому чи іншому вигляді шаблони проектування можуть бути застосовані у всіх додатках. Виявлення оптимальних реалізацій шаблонів становить невід'ємну частину роботи над framework-системою (я б сказав, що справжня framework-система просякнута духом патернів проектування).
Шаблони проектування існують для всіх основних типів завдань, що виконуються CMF-системою. Рішення цих завдань вимагають продуманої стандартизації (зрозуміло, в рамках проекту). Таких завдань декілька:
• Обробка запиту ІС;
• Організація предметної області ІВ;
• Організація подання ІС;
• Організація допоміжних підсистем;
Завдання, які я виділив, занадто умовні, що б вважати їх формальним списком завдань framework-системи. Цей список наведений, що б Ви могли зрозуміти, в яких напрямках розробники концентрують свої зусилля.
Обробка запиту
Підсистема обробки запиту зіставляє запит клієнта з дією, що виконується системою. Запити до системи можуть бути досить «різношерстими». Вони відрізняються як по вигляду, так і за смисловим навантаженням. Це залежить від типу додатка. Самі механізми зіставлення і їх дії можуть змінюватися під час супроводження проекту. Ці вимоги диктують розробникам CMF-системи необхідність створення зручного механізму аналізу та обробки запитів. У разі якщо розробники справляються зі своїм завданням, то додатки, побудовані на базі їх framework-системи, будуть красивими і легко запам'ятовуються адресами кшталт «server.com/news/2013-02-03» замість «server.com/index.php?module=news&action=show&date=2013-02-03». Безумовно, краса запиту не єдине якість, якого домагаються розробники. Гнучкі механізми зіставлення запиту з дією грають дуже важливу роль, так це дуже зміна частина системи.
Організація предметної області
У кожної інформаційної системи є предметна область. Це набір термінів, об'єктів і правил, якими оперує додаток. Організація предметної області, одна з найскладніших завдань, яка сьогодні стоїть перед розробниками. У переважній більшості випадків функціонування предметної області забезпечують реляційні бази даних і об'єктно-орієнтовані технології відображення. Реляційний і об'єктно-орієнтований підхід геніальні окремо. Проте їх композиція, при невмілому поводженні, перетворює архітектуру інформаційної системи в купу мотлоху, розібратися в якій буде важко навіть досвідченому фахівцеві.
Організація подання
Уявлення - це підсистема відображення даних. З її допомогою логіка предметної області відокремлюється від логіки відображення даних. Уявлення - це найстабільніша частина інформаційної системи. Відображення даних може мінятися дуже часто, на відміну від самих даних і методів їх обробки. Тому framework-система повинна надати зручні та гнучкі механізми роботи з логікою відображення. Для вирішення цього завдання використовуються шаблонні системи , чиє завдання полягає у відділенні логіки відображення і укладання її в окремі файли (шаблони відображення), які можна редагувати окремо від усіх інших частин системи. Завдяки цьому, роботу над проектом можна ефективно розпаралелити (Організація предметної області → програміст + адміністратор БД, Організація подання → верстальник + дизайнер).
Організація допоміжних підсистем
Під допоміжними підсистемами мається на увазі набір архітектурних рішень, покликаних полегшити працю програміста. Сюди можна віднести реалізації патернів загального призначення, які безпосередньо не відносяться до інших підсистем. Зокрема до допоміжних підсистем відносяться такі поняття як резолверів, хендла, різний реєстр (и), спостерігачі і т.д. Ці речі можуть бути використані в будь-якій іншій підсистемі для вирішення виникаючих проблем.
Наприклад, патерн singletone (одиночка) може бути використаний для підтримки декількох інстанцій об'єкта в одиничному екземплярі. Це завдання носить суто допоміжний характер і не може бути віднесено безпосередньо до рівня бізнес-логіки або будь-якого іншого.
Проте не варто недооцінювати важливість прийняття рішень по відношенню до цієї підсистемі. Від того наскільки зручними та ефективними будуть реалізації допоміжних патернів, залежить те, наскільки зручно буде програмувати інші підсистеми, і наскільки ефективно вони будуть працювати. Код, написаний у цій підсистемі, багато в чому визначає код, який буде писати програміст, що користується цим framework'ом.
Маленькі бібліотеки
Один з ворогів повторного використання коду - той факт, що люди не складають з свого коду бібліотеки. Клас багаторазового використання може бути похований у директорії однієї з програм і може ніколи не випробувати хвилюючого почуття реінкарнації в новому проекті. І тільки тому, що програміст не захотів винести цей клас (або класи) у бібліотеку.
В ідеальному світі програміст міг би зайти на сайт, подивитися по каталогу або пошуком знайти потрібний пакет бібліотек і закачати собі. Якщо ви можете налагодити таку систему, в якій програмісти на добровільній основі будуть підтримувати базу вихідників - це прекрасно. Якщо ви заведете бібліотекаря, який відстежує коефіцієнт повторного використання, то це просто розкішно.
Інший спосіб - автоматична генерація сховища з початкових кодів. Досягається подібний ефект через використання стандартних заголовків для класів, методів, бібліотек і різних підсистем. Такі заголовки служать водночас технічним керівництвом і пунктами в списку репозиторія.
Файли, що включаються
Можливість повторного використання існуючого коду є дуже важливим, тому що може зберегти час і гроші і сприяти узгодженості. Припустимо, що сайт Web містить текстове меню, яке повторюється на кожній сторінці. Замість повторного кодування меню буде значно легше закодувати його один раз і динамічно включати вміст меню на кожну з окремих сторінок Web. Це можна зробити за допомогою так званого серверного включення файлу.
Файли, що включаються можуть містити будь-який код XHTML або PHP і зазвичай зберігаються з розширенням. Inc, хоча можна використовувати також розширення. Php,. Txt, або. Htm. Вміст файлу, що включається кодується один раз і включається в будь-яку необхідну кількість сторінок PHP. Якщо під файлом, що включається робиться зміна, то оновлення автоматично відбивається на всіх сторінках PHP, які посилаються на цей файл.
