Архітектура CMF-системи

Питання архітектури дуже складні за своєю суттю, і навіть багато фахівців не можуть сказати за п'ять хвилин нічого зрозумілого із приводу якихось конкретних рішень. Але, незважаючи на таку велику контекстну залежність архітектури від типу додатка, існують добре вивчені і перевірені варіанти вирішення архітектурних проблем. Ці варіанти рішення носять назву «шаблони проектування» (Design Patterns). У тому чи іншому вигляді шаблони проектування можуть бути застосовані у всіх додатках. Виявлення оптимальних реалізацій шаблонів становить невід'ємну частину роботи над framework-системою (я б сказав, що справжня framework-система просякнута духом патернів проектування).

Шаблони проектування існують для всіх основних типів завдань, що виконуються CMF-системою. Рішення цих завдань вимагають продуманої стандартизації (зрозуміло, в рамках проекту). Таких завдань декілька:

- Обробка запиту ІС 1);

- Організація предметної області ІВ;

- Організація подання ІС;

- Організація допоміжних підсистем;

Завдання занадто умовні, що б вважати їх формальним списком завдань framework-системи. Цей список наведений, що б Ви могли зрозуміти, в яких напрямках розробники концентрують свої зусилля.

Обробка запиту

Підсистема обробки запиту зіставляє запит клієнта з дією, що виконується системою. Запити до системи можуть бути досить «різношерстими». Вони відрізняються як по вигляду, так і за смисловим навантаженням. Це залежить від типу додатка. Самі механізми зіставлення і їх дії можуть змінюватися під час супроводження проекту. Ці вимоги диктують розробникам CMF-системи необхідність створення зручного механізму аналізу та обробки запитів. У разі якщо розробники справляються зі своїм завданням, то додатки, побудовані на базі їх framework-системи, будуть красивими і легко запам'ятовуються адресами кшталт «http://www.server.com/news/2005-02-03» замість «http: / / www.server.com/index.php?module=news&action=show&date=2005-02-03». Безумовно, краса запиту не єдине якість, якого домагаються розробники. Гнучкі механізми зіставлення запиту з дією грають дуже важливу роль, так це дуже зміна частина системи.

Організація предметної області

У кожної інформаційної системи є предметна область. Це набір термінів, об'єктів і правил, якими оперує додаток. Організація предметної області, одна з найскладніших завдань, яка сьогодні стоїть перед розробниками. У переважній більшості випадків функціонування предметної області забезпечують реляційні бази даних і об'єктно-орієнтовані технології відображення. Реляційний і об'єктно-орієнтований підхід геніальні окремо. Проте їх композиція, при невмілому поводженні, перетворює архітектуру інформаційної системи в купу мотлоху, розібратися в якій буде важко навіть досвідченому фахівцеві.

Організація подання

Уявлення - це підсистема відображення даних. З її допомогою логіка предметної області відокремлюється від логіки відображення даних. Уявлення - це найстабільніша частина інформаційної системи. Відображення даних може мінятися дуже часто, на відміну від самих даних і методів їх обробки. Тому framework-система повинна надати зручні та гнучкі механізми роботи з логікою відображення. Для вирішення цього завдання використовуються шаблонні системи, чиє завдання полягає у відділенні логіки відображення і укладання її в окремі файли (шаблони відображення), які можна редагувати окремо від усіх інших частин системи. Завдяки цьому, роботу над проектом можна ефективно розпаралелити (Організація предметної області → програміст + адміністратор БД, Організація подання → верстальник + дизайнер).

Організація допоміжних підсистем

Під допоміжними підсистемами мається на увазі набір архітектурних рішень, покликаних полегшити працю програміста. Сюди можна віднести реалізації патернів загального призначення, які безпосередньо не відносяться до інших підсистем. Зокрема до допоміжних підсистем відносяться такі поняття як резолверів, хендла, різний реєстр (и), спостерігачі і т.д. Ці речі можуть бути використані в будь-якій іншій підсистемі для вирішення виникаючих проблем.

Наприклад, патерн singletone (одиночка) може бути використаний для підтримки декількох інстанцій об'єкта в одиничному екземплярі. Це завдання носить суто допоміжний характер і не може бути віднесено безпосередньо до рівня бізнес-логіки або будь-якого іншого.

Проте не варто недооцінювати важливість прийняття рішень по відношенню до цієї підсистемі. Від того наскільки зручними та ефективними будуть реалізації допоміжних патернів, залежить те, наскільки зручно буде програмувати інші підсистеми, і наскільки ефективно вони будуть працювати. Код, написаний у цій підсистемі, багато в чому визначає код, який буде писати програміст, що користується цим frameworkом.

Дата добавления: 2017-02-01