Архітектура програмного забезпечення

Даний патерн локалізує залежне від стану поведінку і ділить його на частини, що відповідають станам, переходи між станами стають явними.

Твірні патерни проектування

До породжувальних патернів належать:

* Абстрактна фабрика (Abstract Factory, Factory) - GoF;

* Одинак (Singleton) - GoF;

* Прототип (Prototype) - GoF;

* Творець примірників класу (Creator) - GRASP;

* Будівельник (Builder) - GoF;

* Фабричний метод (Factory Method) або Віртуальний конструктор (Virtual Constructor) - GoF.

Наведемо приклади 2-х даних патернів (табл. 3) .

Таблиця 3. Приклади що породжують патерни класів/об'єктів
Одинак (Singleton) - Go
Проблема	Який спеціальний клас повинен створювати "Абстрактну фабрику" і як одержати до неї доступ? Необхідний лише один екземпляр спеціального класу, різні об'єкти повинні звертатися до цього екземпляра через єдину точку доступу.
Рішення	Створити клас і визначити статичний метод класу, що повертає цей єдиний об'єкт. Розумніше створювати саме статичний екземпляр спеціального класу, а не оголосити необхідні методи статичними, оскільки при використанні методів екземпляра можна застосувати механізм спадкування й створювати підкласи. Статичні методи в мовах програмування не поліморфні й не допускають перекриття в похідних класах. Рішення на основі створення екземпляра є більше гнучким, оскільки згодом може знадобитися вже не єдиний екземпляр об'єкта.
Фабричний метод (Factory Method) або Віртуальний конструктор (Virtual Constructor) - Go
Проблема	Визначити інтерфейс для створення об'єкту, але залишити підкласам рішення про те, який клас інстанціювати, тобто, делегувати інстанціювання підкласами.
Рішення	Абстрактний клас "Творець" оголошує Фабричний Метод, який повертає об'єкт типу "Продукт" (абстрактний клас, що визначає інтерфейс об'єктів, що створюються фабричним методом). "Творець" також може визначити реалізацію за замовчуванням Фабричного Методу, який повертає "КонкретнийПродукт". "КонкретнийТворець" заміщає Фабричний Метод, який повертає об'єкт "КонкретнийПродукт". "Творець" "покладається" на свої підкласи у визначенні Фабричного Методу, що повертає об'єкт "КонкретнийПродукт". Даний патерн позбавляє проектувальника від необхідності вбудовувати в код залежать класів від програми. Однак при застосуванні даного патерну виникає додатковий рівень підкласів.

Архітектурні системні патерни

Структурні патерни

До структурних патернів належать:

* Репозиторій;

* Клієнт / сервер;

* об'єктно - орієнтований, Модель предметної області (Domain Model), модуль таблиці (Data Mapper);

* Багаторівнева система (Layers) чи абстрактна машина;

* Потоки даних (конвеєр або фільтр).

Наведемо приклад одного із даних патернів (табл. 4).

Таблиця 4. Приклади стуктурних патернів архітектури
Багаторівнева система (Layers) або абстрактна машина
Опис	Відповідно до патерна "Багаторівнева система" структурні елементи системи організуються в окремі рівні з взаємопов'язаними обов'язками таким чином, щоб на нижньому рівні розташовувалися низькорівневі служби та служби загального призначення, а на більш високих - об'єкти рівня логіки додатка. При цьому взаємодія і зв'язування рівнів відбувається зверху вниз. Зв'язування об'єктів знизу вгору слід уникати. На малюнку показані типові рівні логічної архітектури системи. Шар подання охоплює все, що має відношення до спілкування користувача з системою. До основних функцій шару подання відноситься відображення інформації й інтерпретація користувачем команд з перетворенням їх у відповідні операції в контексті домену (бізнес - логіка) і джерела даних. Джерело даних - підмножина функцій, що забезпечує взаємодію зі сторонніми системами, які виконуються. На відміну від архітектурного патерну "Клієнт - сервер", шари зовсім не обов'язково повинні розташовуватися на різних машинах. Багаторівнева система може бути розроблена покрокова (Ітеративний). Недоліками даного патерну є: * Зміна вихідного коду тягне за собою переробку всіх елементів системи, оскільки всі елементи системи тісно пов'язані один з одним. * Логіка програми тісно пов'язана з інтерфейсом користувача - важко міняти інтерфейс або принципи реалізації логіки. Через високу пов'язаність, роботу з реалізації системи складно розділити між розробниками і, крім того, складно модифікувати функції додатку або переходити на нові технології.

До патернів управління відносяться :

· Патерни централізованого управління

· Виклик - повернення (сценарій транзакції - окремий випадок)

· Диспетчер

· Патерни управління, засновані на подіях

· Передача повідомлень

· Керування перериваннями

· Патерни, що забезпечують взаємодію з базою даних

· Активний запис (Active Record)

· Одиниця роботи (Unit Of Work)

· Завантаження на вимогу (Lazy Load)

· Колекція об'єктів (Identity Map)

· Безліч записів (Record Set)

· Успадкування з однією таблицею (Single Table Inheritance)

· Успадкування з таблицями для кожного класу (Class Table Inheritance)

· Оптимістичне автономне блокування (Optimistic Offline Lock)

· Відображення з допомогою зовнішніх ключів

· Відображення з допомогою таблиці асоціацій (Association Table Mapping)

· Песимістичне автономне блокування (Pessimistic Offline Lock)

· Поле ідентифікації (Identity Field)

· Перетворювач даних (Data Mapper)

· Збереження сеансу на стороні клієнта (Client Session State)

· Збереження сеансу на стороні сервера (Server Session State)

· Шлюз запису даних (Row Data Gateway)

· Шлюз таблиці даних (Table Data Gateway)

У даній лекції приклади патернів управління розглядатися не будуть.

Патерни, призначені для представлення даних у Web

До патернів, призначених для представлення даних у Web, відносяться:

* Модель-представлення-контролера (Model View Controller);

* Контролер сторінок (Page Controller);

* Контролер запитів (Front Controller);

* Представлення за шаблоном (Template View);

* Представлення з перетворенням (Transform View);

* Двоетапне подання (Two Step View);

* Контролер додатка (Application Controller).

Наведемо приклад 4-х патернів (табл. 5) [18].

Таблиця 5. Приклади патернів, призначених для представлення даних у Web
Модель-подання-контролера (Model View Controller)
Опис	Типове рішення модель-подання-контролера має на увазі виділення трьох окремих ролей. Модель - це об'єкт, що дає деяку інформацію про домен. У моделі немає візуального інтерфейсу, вона містить у собі всі дані і поведінку, не пов'язані з призначеним для користувача інтерфейсом. В об'єктно-орієнтованому контексті найбільш "чистою" формою моделі є об'єкт моделі предметної області. В якості моделі можна розглядати і сценарій транзакції, якщо він не містить в собі ніякої логіки, пов'язаної з призначеним для користувача інтерфейсом. Подібне визначення не дуже розширює поняття моделі, однак повністю відповідає розподілу ролей у розглянутому типовому рішенні. Представлення відображає вміст моделі засобами графічного інтерфейсу. Таким чином, якщо модель - це об'єкт покупця, відповідне подання може бути фреймом з купою елементів управління або HTML-сторінкою, заповненою інформацією про покупця. Функції подання полягають тільки у відображенні інформації на екрані. Всі зміни інформації обробляються третім "учасником" системи - контролером. Контролер одержує вхідні дані від користувача, виконує операції над моделлю і вказує подання на необхідність відповідного оновлення. У цьому плані графічний інтерфейс можна розглядати як сукупність подання та контролера. Говорячи про типове рішення модель-подання-контролер, не можна не підкреслити два основні типи поділу: відділення подання від моделі та відділення контролера від подання. Відділення подання від моделі - це один з фундаментальних принципів проектування програмного забезпечення. Наявність такого поділу дуже важливо з ряду причин: * Представлення і модель відносяться до абсолютно різних сфер програмування. * Користувачі хочуть, щоб, залежно від ситуації, одна і та ж інформація могла бути відображена різними способами. * Об'єкти, що не мають візуального інтерфейсу, набагато легше тестувати, ніж об'єкти з інтерфейсом. Ключовим моментом у відділенні подання від моделі є спрямування залежностей: представлення залежить від моделі, але модель не залежить від подання. Це означає, що зміна уявлення не вимагає зміни моделі. Відділення контролера від подання. Класичним прикладом необхідності такого поділу є підтримка редагованої і не редагованої поведінки. Цього можна досягти за наявності одного подання і двох контролерів (для двох варіантів використання), де контролери є стратегіями, використовуваними поданням. Тим часом на практиці в більшості систем кожному поданню відповідає тільки один контролер, тому поділ між ними не проводиться. Про це рішення згадали тільки з появою Web-інтерфейсів, де відділення контролера від подання виявилося надзвичайно корисним. .
Контролер сторінок (Page Controller)
Опис	В основі контролера сторінок лежить ідея створення компонентів, які будуть виконувати роль контролерів для кожної сторінки Веб-сайту. На практиці кількість контролерів не завжди в точності відповідає кількості сторінок, оскільки інколи при натисканні на посилання відкриваються сторінки з різним динамічним вмістом. Якщо говорити більш точно, контролер необхідний для кожної дії, під яким мається на увазі клацання на кнопці або гіперпосиланні. Контролер сторінок може бути реалізований у вигляді сценарію (сценарію CGI) або сторінки сервера (ASP, PHP, JSP і т.д.). Використання сторінки сервера зазвичай передбачає поєднання в одному файлі контролера сторінок та подання за шаблоном. Це добре для подання за шаблоном, але не дуже підходить для контролера сторінок, оскільки значно ускладнює правильне структурування цього компоненту. Дана проблема не настільки важлива, якщо сторінка застосовується тільки для простого відображення інформації. Тим не менш, якщо використання сторінки припускає наявність логіки, пов'язаної з отриманням даних користувача або вибором подання для відображення результатів, сторінка сервера може заповнитися кодом впровадженого сценарію. Щоб уникнути подібних проблем, можна скористатися допоміжним об'єктом (helper object). При отриманні запиту сторінка сервера викликає допоміжний об'єкт для обробки всієї наявної логіки. У залежності від ситуації, допоміжний об'єкт може повернути управління первісної сторінки сервера або ж звернутися до іншої сторінки сервера, щоб вона виступила як представлення. У цьому випадку обробником запитів є сторінка сервера, проте велика частина логіки контролера укладена у допоміжному об'єкті. Можливою альтернативою описаного підходу є реалізація обробника і контролера у вигляді сценарію. У цьому випадку під час вступу запиту веб-сервер передає управління сценарієм; сценарій виконує всі дії, покладені на контролер, після чого відображає отримані результати з допомогою потрібного подання. Нижче перераховані основні обов'язки контролера сторінок. * Проаналізувати адресу URL і витягти дані, введені користувачем у відповідні форми, щоб зібрати всі відомості, необхідні для виконання дії. * Створити об'єкти моделі і викликати їх методи, необхідні для обробки даних. * Визначити подання, яке повинно бути використано для відображення результатів, і передати йому необхідну інформацію, отриману від моделі. Контролер сторінок не обов'язково повинен являти собою єдиний клас, зате всі класи контролерів можуть використовувати одні й ті ж допоміжні об'єкти. Це особливо зручно, якщо веб-сервер повинен мати кілька обробників, що виконують аналогічні завдання. У цьому випадку використання допоміжного об'єкту дозволяє уникнути дублювання коду. При необхідності одні адреси URL можна обробляти за допомогою сторінок сервера, а інші - за допомогою сценаріїв. Ті адреси URL, у яких немає або майже немає логіки контролера, добре обробляти за допомогою сторінок сервера, тому що останні є простим механізмом, зручним для розуміння та внесення змін. Всі інші адреси, для обробки яких необхідна більш складна логіка, вимагають застосування сценаріїв.
Контролер запитів (Front Controller)
Опис	Контролер запитів обробляє всі запити, що надходять до Веб-сайту, і зазвичай складається з двох частин: Веб-обробника та ієрархії команд. Веб-обробник - це об'єкт, який виконує фактичне отримання POST або GET-запитів, що надійшли на Веб-сервер. Він витягає необхідну інформацію з адреси URL і вхідних даних запиту, після чого вирішує, яку дію необхідно ініціювати, і делегує його виконання відповідної команді. Веб-обробник зазвичай реалізується у вигляді класу, а не сторінки сервера, оскільки він не генерує жодних відгуків. Команди також є класами, а не сторінками сервера, більше того, їм не потрібно знати про наявність Веб-оточення, не дивлячись на те, що їм часто передається інформація з HTTP-запитів. У більшості випадків Веб-обробник - це досить проста програма, функції якої полягають у виборі потрібної команди. Вибір команди може відбуватися статично або динамічно. Статичний вибір команди - це проведення синтаксичного аналізу адреси URL і застосування умовної логіки, а динамічний - витяг деякого стандартного фрагмента адреси URL і динамічне створення екземпляра класу команди. Переваги статичного вибору команди перебувають у використанні явного коду, наявності перевірки часу компіляції і високої гнучкості можливих варіантів написання адрес URL. У свою чергу, використання динамічного підходу дозволяє додавати нові команди, не вимагаючи зміни Веб-обробника. При динамічному виборі команд ім'я класу команди можна помістити безпосередньо на адресу URL або скористатися файлом властивостей, який буде прив'язувати адреси URL до імен класів команд. Зрозуміло, це потребує створення додаткового файлу властивостей, однак дозволить легко і невимушено змінювати імена класів, не переглядаючи всі наявні на сервері Веб-сторінки.
Подання за шаблоном (Template View)
Опис	Основна ідея, що лежить в основі типового рішення уявлення за шаблоном, - вставка маркерів в текст готової статичної HTML-сторінки. При виклику сторінки для обслуговування запиту ці маркери будуть замінені результатами деяких обчислень (наприклад, результатами виконання запитів до бази даних). Подібна схема дозволяє створювати статичну частину сторінки за допомогою звичайних засобів, наприклад текстових редакторів, що працюють за принципом WYSIWYG, і не вимагає знання мов програмування. Для отримання динамічної інформації маркери звертаються до окремих програм. Подання за шаблоном використовується цілим рядом програмних засобів. Таким чином, завдання полягає не стільки в тому, щоб розробити дане рішення самому, скільки в тому, щоб навчитися його ефективно використовувати і познайомитися з можливими альтернативами.

Патерни інтеграції корпоративних інформаційних систем

Структурні патерни інтеграції

До структурних патернів інтеграції належать :

* Взаємодія "точка - точка";

* Взаємодія "зірка" (інтегруюча середовище);

* Змішаний спосіб взаємодії.

У даній лекції приклади структурних патернів інтеграції розглядатися не будуть.

Патерни за методом інтеграції

До патернів за методом інтеграції належать:

* Інтеграція систем за даними (data-centric);

* Функціонально-центричний (function-centric) підхід;

* Об'єктно-центричний (object-centric);

* Інтеграція на основі єдиної понятійної моделі предметної області (concept-centric).

Патерни інтеграції за типом обміну даними

До патернів інтеграції за типом обміну даними відносяться :

* Файловий обмін;

* Загальна база даних;

* Віддалений виклик процедур;

* Обмін повідомленнями.

У даній лекції приклади патернів інтеграції за типом обміну розглядатися не будуть.

Model-Viewer-Controller

Стандартна схема архітектури «Модель-Вид-Контролер» зображена на наступному малюнку: (схема запозичена з книги «Ajax in action» видавничого дому «Вільямс»)

Схема архітектури MVC

Розберемо по пунктах дану схему.

У шаблоні MVC, як випливає з назви, є три основних компоненти: Модель, Представлення, і Контролер.

Представлення відповідає за відображення інформації, що надходить із системи або в систему.

Модель є «суттю» системи і відповідає за безпосередні алгоритми, розрахунки тощо внутрішній устрій системи.

Контролер є сполучною ланкою між «поданням» і «моделлю» системи, за допомогою якого і існує можливість зробити поділ між ними. Контролер отримує дані від користувача і передає їх в «модель». Крім того, він отримує повідомлення від моделі, і передає їх в «подання».

Стосовно до інтернет-додатків існує думка, що частини контролера і подання об'єднані, тому що за відображення і одночасно за введення інформації відповідає браузер. З цим можна погодитися, а можна не погоджуватися і виділити контролер в окрему частину, що ми і зробимо.

Отже, домовимося:

Представлення. Модуль виведення інформації. Це може бути шаблонізатор або що-небудь подібне, мета якого є тільки в поданні інформації у вигляді HTML на основі будь-яких готових даних.

Контролер. Модуль управління введенням і виведенням даних. Даний модуль повинен стежити за переданими в систему даними (через форму, рядок запиту, cookie або будь-яким іншим способом) і на основі введених даних вирішити:

* Передавати чи їх у модель

* Вивести повідомлення про помилку і запросити повторне введення (змусити модуль уявлення оновити сторінку з урахуванням умов)

Крім того, контролер зобов'язаний визначати тип даних, отриманих від моделі (чи є це готовий результат, відсутність повідомлення про помилку) і передавати інформацію в модуль уявлення.

Модель. Модуль, що відповідає за безпосередній розрахунок чого-небудь на основі отриманих від користувача даних. Результат, отриманий цим модулем, повинен бути переданий в контролер, і не повинен містити нічого, що відноситься до безпосереднього висновку (тобто має бути представлений у внутрішньому форматі програми).

Досить складно з першого разу розібратися і зрозуміти. На це потрібен час і відповідний проект.

Але насправді нічого надскладного в цьому немає.

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

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

Цей же клас повинен передати дані, отримані в результаті роботи моделі, в клас представлення для виводу.

Одними словами схему потоків даних у цій архітектурі пояснити складно, тому звернемося до мови UML і до діаграми послідовностей зокрема (незначні відступи від UML, прийняті в діаграмах, полягають в тому, що в деяких випадках разом з іменами сутностей або об'єктів, дані переказують в дужках).

На цій діаграмі показана послідовність дій, а також послідовність переданих даних: від користувача, до користувача і між модулями.

Схема відображає типовий процес виведення форми, заповнення її користувачем і повернення користувачеві результатів. Ніяких помилок в даному випадку не відбувається.

Діаграма послідовностей

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

Тепер спробуємо скласти діаграму класів для більшої наочності.

Діаграма класів

Діаграма класів містить три класи, по одному для кожного компонента архітектури MVC. Для зручності, вони так і названі: Model, View, Controller.

У поданні є три функції (хоча, цілком можливо обійтися тільки лише однією), які відповідають за відображення стану програми:

displayDefault () - висновок форми за замовчуванням.

displayError (error = false) - висновок форми з повідомленням про помилку,

displayResults () - висновок результатів обчислень

Контролер має не тільки методи, а й поля. З полями все просто: це помилка і результати обчислень. За замовчуванням їм задається значення false, що свідчить про те, що поки немає ні помилки, ні результатів.

Три методи, присутні в контролері, служать для управління та перевірки. Метод для перевірки (validate ()) є необов'язковим, і цілком може бути відсутнім, якщо ніяких перевірок не потрібно.

Метод processData () служить для виведення форми за замовчуванням, однак він включає також методuserRequest (), функціональність якого виконується лише в тому випадку, коли є введені користувачем дані. Саме метод userRequest () містить у собі функцію validate () (якщо дані не введені, отже, нема чого робити їх перевірку) і, крім того, повинен міститись виклик конструктора класу моделі.

У моделі може міститися будь-яка кількість полів і методів. Однак два методи повинні бути обов'язковими (або навіть один. Як зручніше буде).

calculate () - функція, яка виробляє основний розрахунок

getData () - функція, яка повертає дані результату.

Поділ функцій моделі швидше смислове. Цілком достатньо створити один метод, який буде і рахувати, і повертати результат.

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

Якщо функція validate () контролера виявила помилку, і встановила значення поля error в значення, відмінне від false, контролер сам викличе метод displayError () класу View.

Тепер доречно навести ту ж саму діаграму послідовності, але замінивши в ній смислові значення, назвами функцій класів з відповідної діаграми.

Діаграма послідовностей

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

Наприклад, у виставі ми можемо написати:

/ / Це код на PHP

public function displayDefault () {

echo "<p> Введіть ім'я:";

echo "<input type='text' name='name' value=''>";

}

А потім через місяць жахнутися, і перейти до використання шаблонізатора. Скажімо, smarty.

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

У висновку, хотілося б все ж таки привести деякий скелет коду на PHP для кращого засвоєння ідеї MVC.

<?

/ **

* Приклад реалізації MVC на PHP

*

** /

class Controller {

private $ error;

private $ result;

function __construct () {

$ This-> error = false;

$ This-> result = false;

}

function processData () {

$ This-> userRequest ();

if ($ this-> error)

View:: displayError ($ this-> error);

else

if ($ this-> result)

View:: displayResults ($ this-> result);

else

View:: displayDefault ();

}

function userRequest () {

/ / Дані відправлені

if (isset ($ _POST ['send'])) {

$ This-> validate ();

if (! $ this-> error) {

/ / Основні обчислення

$ Model = new Model ();

$ Model-> calculate ($ _POST ['name']);

$ Result = $ model-> getData ();

/ / Перевірка на помилки в самій моделі

if (! is_array ($ result))

$ This-> error = $ result;

else

$ This-> result = $ result;

}

}

}

function validate () {

if (empty ($ _POST ['name']))

$ This-> error = 'Не введено ім'я!';

else

if (strlen (strval ($ _POST ['name'])) <3)

$ This-> error = 'Ім'я занадто коротке!';

}

} / / Class Controller

class View {

static function displayDefault () {

echo "<form method='POST' action=''>";

echo "<p> Введіть ім'я:";

echo "<input type='text' name='name' value=''>";

echo "<input type='submit' name='send' value='Отправіть'>";

echo "</ form>";

}

static function displayError ($ error) {

echo "<p> <b> Помилка: </ b> {$ error}";

View:: displayDefault ();

}

static function displayResults ($ results) {

echo "<p> <b> Результати: </ b>";

echo "<p> Ваше ім'я <b>". $ results [0].

"</ B> означає <i>". $ Results [1 ]."</ i> ";

echo "<p> <a href ='".$_ SERVER ['REQUEST_URI'].

"'> Дізнатися ще про одне імені </ a>";

}

} / / Class View

class Model {

private $ data;

function __construct () {

$ This-> data = false;

}

function calculate ($ name) {

$ This-> data [] = $ name;

$ Len = strlen ($ name);

if ($ len == 3)

$ This-> data [] = 'стислість - сестра таланту';

else

if (($ len> 3) & & ($ len <6))

$ This-> data [] = '... немає особливого значення';

else

$ This-> data [] = 'неймовірно багата фантазія батьків';

}

function getData () {

if ($ this-> data)

return $ this-> data;

else

return 'Обчислення не проведені!';

}

} / / Class Model

$ Controller = new Controller ();

$ Controller-> processData ();

?>

Отже, ми отримали найпростішу MVC-систему. Виділимо позитивні і негативні сторони:

До мінусів можна віднести

* Збільшення обсягу коду

* Необхідність дотримання заздалегідь заданого інтерфейсу

* Для підтримки розробки потрібні більш кваліфіковані фахівці

Остання вимога до нашого прикладу не відноситься, але для реальних систем воно досить актуально.

До плюсів віднесемо наступне:

* Безсумнівно більш гнучкий код

* Можливість повторного використання кожної з трьох складових частин MVC

* Безболісна заміна моделі (інші алгоритми розрахунку, способу зберігання даних і т.д.)

* Досить просто перейти від одного подання, до іншого (від HTML до XML або JSON)

Треба сказати, що код прикладу не ідеальний. У ньому є простори для рефакторингу (незважаючи на те, що він займає трохи більше ста рядків). Скажімо, у прикладі бере участь всього лише одна змінна, яка надходить від користувача (name), але що якщо їх буде багато?

Размещено на Allbest.ru