Перевірка даних вводу користувача (Validation)

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

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

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

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

4. Дизайн бізнес-рівню

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

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

Business Logic components. Бізнес-логіка визначається як будь-яка логіка за- стосування, яка пов'язана з пошуком, обробкою, перетворення і управління даними застосувань, застосування бізнес-правила і політики, і забезпечення цілісності і коректності даних. Для максимізації можливості повторного ви- користання, компоненти бізнес-логіки, не повинні містити поведінку або ло- гіку, характерні для конкретного варіанту або сценарію використання . Ком- поненти бізнес-логіки можуть далі підрозділятися на наступні дві категорії:

• Компоненти управління потоком виконання(Business Workflow) components.Після того, як компоненти призначеного для користувача ін-

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

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

4. Дизайн бізнес-рівню

   1. Рекомендації з проектування

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

При проектуванні бізнес-шару дотримуйтеся наступних рекомендацій:

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

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

• Уникати змішення компонентів різних типів. необхідно відокреми- ти бізнес-логіку від логіки представлення і доступу до даних і спростити тестування бізнес-функціональності. Також використайте бізнес-шар, щоб

централізувати функції бізнес-логіки і забезпечити можливість повторно- го використання.

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

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

2. Кроки по дизайну рівня бізнес-логіки

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

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

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

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

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

4. Проектування рівню даних

Рівень даних складається з:

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

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

1. Кроки з проектування рівню даних Ключові дії розробки рівня сервісу :

1. Створення загального дизайну рівня даних. Визначення обмежень, які накладаються джерелами даних.

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

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

4. Проектування компонентів доступу до даних. Необхідно перерахувати усі джерела даних і визначити метод доступу до кожного джерела да- них.

При проектуванні рівня даних необхідно враховувати наступне:

• Використання механізмів абстракції для реалізації слабо-зв'язних інте- рфейсів доступу до рівня даних(loosely coupled) . Для цієї мети можуть використовуватися компоненти інтерфейсу, такі як шлюз з відомими вхі- дними і вихідними даними, який перетворить запити у формат, зрозумі- лий компонентам рівня даних.

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

• Визначення способу відображення сутностей(об'єктів), якими оперує застосування на структури, використовувані джерелами даних.

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

• Визначення способу управління з'єднаннями.

• Визначення способу управління виключеннями. На рівні даних повинні перехоплюватися і оброблятися виключення пов'язані з джерелами даних і операціями створення /чтения/обновления/удаления данных.

• Розгляд ризиків безпеки. На рівні даних повинні запобігати спроби крадіжки, псування даних і несанкціонованого доступу до даних.

• Зменшення числа звернень до зовнішніх джерел даним. Можливість злиття набору команд в єдину операцію доступу до даних.

• Оптимізація продуктивності і розширюваності.

2. Специфічні проблеми проектування рівню даних

• Batching(Пакетування)

• Binary Large Objects(BLOBs)

• З'єднання

• Формат даних

• Управління виключеннями

• Реляційне відображення об'єктів(Object Relational Mapping)

• Запити

• Процедури, що зберігаються

• Транзакції

• Перевірка коректності даних(Validation)

• XML