Визначення наскрізної функціональності

Після того, як визначені рівні застосування, необхідно визначити типи функціональності, яка перетинає межі рівнів(crosscutting concerns). Зазвичай такі види функціональності включають журналирование(logging), кеширова- ние(caching), визначення коректності значень(validation), аутентифікація, і управління виключеннями. Важливо використати окремі компоненти, що відповідають за подібні види функціональності.

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

Визначення інтерфейсу між рівнями

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

Вибір стратегії реалізації і впровадження

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

Вибір протоколів взаємодії

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

3. Дизайн Рівню Представлення

Рівень представлення містить компоненти, які реалізують і відображають ін- терфейс користувача і відповідають за взаємодію з користувачем.

Зазвичай рівень представлення включає наступне:

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

• Компоненти логіки представлення. Логіка представлення це код засто- сування, який визначає логічно поведінку і структуру застосування неза- лежно від способу реалізації інтерфейсу користувача.

Рівень представлення включає також компоненти моделі представлен- ня(Presentation Layer Model), що інкапсулюють дані бізнес - рівня у формі, зручній для використання на рівні представлення.

Дизайн рівня представлення включає наступні кроки:

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

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

• Дизайн інтерфейсу користувача. Необхідно вирішити, чи повинен інте- рфейс бути модульним, і, визначити спосіб розділення функціональності на рівні представлення. Розгляньте патерни представлення, такі як Модель представлення(Presentation Model), Модель - Представлення- контроллер(MVC)

• Визначте стратегію перевірки даних, що вводяться. Використайте ме- тоди перевірки введення щоб захистити систему від підозрілих вхідних даних. Визначте стратегію обробки виключень і протоколювання.

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

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

• Інтерфейс перевірки введення(UI Validation). Для випадку прос- тих застосувань, де бізнес-логіка використовується для перевірки вве- дення користувача, функціональність бізнес логіки може бути реалізо- ваний в компонентах призначеного для користувача інтерфейсу. Проте потрібно потрібно утримуватися від змішення будь-якої бізнес-логіки, яка не відноситься до перевірки введення з компонентами інтерфейсу користувача.

• Компоненти Бізнес-процеса. Для складніших застосувань, на- приклад, застосувань, що використовують транзакції, або застосувань в яких використання бізнес-логіки виходить за рамки простої перевірки введення, бізнес-логіка повинні розташовуватися в отдельныъх компо- нентах, які сипользуются компонетами призначеного для користувача інтерфейсу.

• Модель сфери застосування(Domain Model). Для складних кор- поративних застосувань, де бізнес-логіка спільно сипользуется безліч- чю застосувань, необхідно розглянути варіант виділення бизнес- компонетов в окремий логічний рівень. Цей підхід дозволить розмісти- ти шар бізнес-логіки на окремому фізичному рівні(physical tier) щоб поліпшити розширюваність і можливість повторного використання ін- шими застосуваннями.

• Модуль управління бізнес-правилами(Rules Engine). У застосу- ваннях, які повинні підтримувати комплексну перевірку, управління процесами, логіку сфери застосування, бізнес-логіка може бути реалі- зована модулем управління бізнес-правилами.

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

• Явний виклик функцій(Direct method calls). Якщо логічний рі- вень(layer), з яким виконується обмін даними знаходиться на тому ж фізичному рівні(tier), то може використовуватися явний виклик функк- ций .

• Web services. Якщо доступ до даних або бізнес-логіки повинен розділятися між безліччю застосувань, то має сенс використати інтер-

фейс веб - сервісів( Web service) у разі, якщо бізнес логіка і дані роз- ташовані на окремих з редставлением фізичних рівнях, або їх розді- лення грає важливо .

3. Дизайн Рівню Представлення

   1. Ключові принципи дизайну рівня представлення

• Вибір відповідної технології UI. Необхідно визначити, який тип клієнта буде реалізований - " товстий" клієнт(rich/smart), Web- клієнт, або інтер- нет-застосування(Rich Internet application). Рішення має бути обгрунтоване вимогами пприложения і обмеженнями - організаційними і інфраструкту- ри.

• Використання відповідних шаблонів. Используйет готові патерни рівня представлення в якості перевірених рішень існуючих проблем.Основний патерн Роздільного Представлення(Separated Presentation), відділяє функ- ціональність, специфічну для рівня представленияw від логіки іншого за- стосування, - може бути застосований до усіх типів застосувань. Специфі- чні патерни MVC, MVP, і Упраляющий Презентер( Supervising Presenter) широко використовуються на рівні представлення застосувань що вико- ристовують " товстий" клієнт(rich client) і інтернет застосувань(RIA). Ва- ріації патернів Model - View - Controller(MVC) і Model - View - Presenter(MVP) можуть використовуватися Web - застосуваннями.

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

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

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