Архитектура Web приложения Многослойная архитектура (2- слойная, 3-слойная) & MVC

Обзор Независимость данных в реляционной СУБД N-уровневая архитектура Шаблона проектирования Модель MVC

НЕЗАВИСИМОСТЬ ДАННЫХ В РЕЛЯЦИОННОЙ СУБД Отделение представления от логики и данных

Архитектура базы данных и представления Жестки диск User 1User 2 View 2View 1 Схема БД Система хранения То что видит пользователь Таблицы и ссылки Файлы на диске Каждый уровень не зависит от уровня ниже

Логический и физический уровни Жестки диск User 1User 2 View 2View 1 Схема БД Система хранения Логический уровень Физический уровень

Независимость данных Логическая независимость: возможность изменять логическую схему без изменения внешнего вида (кода приложения) – Можно добавлять новые поля, новые таблицы без изменения представления – Можно изменять структуру таблиц без изменения представления Физическая независимость: возможность изменять физическую схему без изменения логической схемы – Можно изменять размер пространства хранения – Тип данных может быть изменён по причинам оптимизации Нужно всегда отделять представление - VIEW (то что видит пользователь) от модели- MODEL (данных сервиса)

N-УРОВНЕВАЯ АРХИТЕКТУРА

Необходимость слоёв N-уровневая архитектура имеет следующие компоненты: – Уровень представления – Уровень бизнес логики – Данные N-уровневая архитектура пытается разделить компоненты на разные уровни (слои): – Физическое разделение – Логическое разделение

1-уровневая архитектура Все 3 слоя на одной машине – Весь код и все процессы происходят на одной машине Представление, логика, уровень данных сильно связаны – Расширяемость (Scalability): на одном процессоре можно запустить только ограниченное число процессов – Переносимость (Portability): для перемещения на новую машину придётся переписать весь код – Поддержка (Maintenance): при изменении одного слоя придётся изменять остальные Data Base Presentation Logic Business Logic Data Access Logic Приложение

2-уровневая архитектура База данных работает на сервере – Отделение данных от клиента – Клиент может переключить базу данных Отделение представления от данных – Высокая нагрузка на сервер – Потенциальные проблемы с задержкой в сети – Уровень представления и логики остаются сильно связанны Business Logic Presentation Logic Data Access Logic Data Base Data Layer Client Server

3-уровневая архитектура Каждый слой может быть потенциально запущен на отдельной машине Представление логика и данные разделены Presentation Layer Содержит Presentation Logic Business Layer Содержит Business Logic Data Layer Содржит Data Access Logic Data Base ClientServerDB Server

Любое приложение Взять общее число клиентов Число клиентов 4 Взять список клиентов за последний год Сложить всех клиентов вместе Запрос Клиент 1 Клиент 2 Клиент 3 клиент 4 База данных Хранилище Уровень представления Уровень логики Уровень данных Принципы архитектуры: Клиент-серверная архитектура Каждый слой (данные, представление и логика) не зависит от остальных и не зависит от реализации Несоединённые слои вообще никогда не взаимодействуют Изменение платформы влияет только на тот уровень который на ней находится

Любое приложение Взять общее число клиентов Число клиентов 4 Взять список клиентов за последний год Сложить всех клиентов вместе Запрос Клиент 1 Клиент 2 Клиент 3 клиент 4 База данных Хранилище Уровень представления Уровень логики Уровень данных Предоставляет графический интерфейс Обрабатывает пользовательские события Иногда называют GUI или client view of front- end

Любое приложение Взять общее число клиентов Число клиентов 4 Взять список клиентов за последний год Сложить всех клиентов вместе Запрос Клиент 1 Клиент 2 Клиент 3 клиент 4 База данных Хранилище Уровень представления Уровень логики Уровень данных Набор правил для работы с данными Может обрабатывать запросы нескольких пользователей Иногда называют middleware или back- end Недолжен содержать пользовательских форм или непосредственно обращаться к данным

Любое приложение Взять общее число клиентов Число клиентов 4 Взять список клиентов за последний год Сложить всех клиентов вместе Запрос Клиент 1 Клиент 2 Клиент 3 клиент 4 База данных Хранилище Уровень представления Уровень логики Уровень данных Физическое хранилище для данных (persistence) Управляет доступом к БД или файловой системе Иногда называется back- end Недолжен содержать пользовательских форм или бизнес логики

3-уровневая архитектура Уровень представления – Статический или динамически сгенерированный контент отображаемый через браузер (front-end) Уровень логики – Уровень подготовки данных для динамически генерируемого контента, уровень сервера приложений (application server). Middleware платформы: JavaEE, ASP.NET, PHP, ColdFusion Уровень данных – База данных включающая в себя данный и систему управления над ними или же готовая RDBMS система, предоставляющая доступ к данным и методы управления (back-end)

Преимущества Независимость уровней – Лёгкость в поддержке – Отдельные компоненты можно использовать в других задачах – Задача разработки хорошо делится и поэтому может быть быстрее решена (уровни можно разрабатывать параллельно) Web дизайнер делает уровень представления Инженер (Software Engineer) делает логику Администратор БД делает модель данных

ШАБЛОНЫ ПРОЕКТИРОВАНИЯ Design Patterns

Проблемы в дизайне и их решения Разработка и тестирование – Как сделать web приложение? – Какую технику стоит выбрать? Повторное использование – Можно ли использовать стандартные компоненты? Масштабируемость – Как приложение будет справляться с огромным числом запросов? Безопасность – Как защититься от атак приложения, скомпрометированных данных, вирусов и отказов сервиса? Представления данных – Типы, индивидуальные учётные записи, защита данных Нужно одно общее и многоразовое решение: Шаблоны проектирования

Что такое шаблоны проектирования? Общее и многоразовое решение наиболее общих проблем построения архитектуры программы Шаблон описывает то как решить проблему в большинстве подобных ситуаций Это не конечный дизайн – Шаблон всегда должен быть адаптирован для приложения – Нельзя просто транслировать общие идеи в код

Происхождение Шаблонов Проектирования Architectural concept by Christopher Alexander (1977/79) Adapted to OO Programming by Beck and Cunningham (1987) Popularity in CS after the book: Design Patterns: Elements of Re- useable Object-oriented software, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Сейчас шаблоны проектирования широко используются в разработки коммерческих приложений

ШАБЛОН ПРОЕКТИРОВАНИЯ MVC

Проблема Нужно изменить внешний вид без изменения логики (ядра приложения) Нужно представлять данные в различном контексте (т.е. мощный десктоп, web браузер или мобильный телефон) Нужно взаимодействовать с данными из различного контекста (т.е. touch экран планшета или клавиатура компьютера) Нужно иметь несколько представлений для одних и тех же данных (т.е. список, миниатюры, пр.)

Решение Отделить ядро функциональности от представления и логику правления, использующую эту функциональность Позволить нескольким представлениям разделять одни и те же данные Сделать подожку нескольких клиентов (клиентских частей приложения, представений) проще

Модель Model-View-Controller Такая схема помогает отделить модель от представления Так обслуживание данных (файл с текстом или БД) отделено от представления (график или список) и того как данные будут обрабатываться (GUI или командная строка)

Модель Model-View-Controller Модель – Управляет поведением и данными приложения – Отвечает на запросы о своём состоянии (часто для представления) – Следуя инструкциям изменяет состояние (часть для контроллера) Представление – Обрабатывает модель в форму удобную для взаимодействия, в пользовательский интерфейс (несколько представление могут обрабатывать одну модель для разных целей) Контроллер – Получает пользовательские данные и инициирует вызов модели – Получает пользовательские данные и инструкции для модели и отображения производит действия исходя из этих данных

На практике Модель – Содержит специфические здания о приложении – Записи статуса приложения – Часта связано с БД – Не зависит от представления Одна модель для нескольких представлений Представление – Представляет данные пользователю – Позволяет пользователю производить действия – Не обрабатывает ничего самостоятельно Контроллер – Описывает как реагирует интерфейс на события пользователя – Получает сообщения от представления – Взаимодействует с моделью (Говорит что за данные следует показывать)

MWC для Web приложения Модель – Таблицы данных – Данные сессии – Правила руководящие транзакцией Представление – (X)HTML – CSS – Шаблоны обрабатываемые на стерне сервера (JSP) Контроллер – Клиентские скрипты – Процесс обработки http – Бизнес логика

Преимущества MVC Простой дизайн – Модель предоставляет API для данных и состояний – Упрощает разработку модели и контроллера Модульность – Любой компонент может быть легко заменён Множественное представление – Можно добавлять новые представления по мере необходимости – Каждое представление используете одно и тоже API для модели Легко дорабатывать и поддерживать – Можно создать простое (текстовое) представления для отладки модели – Остальные представления и контроллеры могут быть добавлены позже – Проще создать стабильный интерфейс Распределение – Распределение приложение выглядит естественно (разнести компоненты по разным машинам)

MVC против 3-ч уровневой архитектуры Взаимодействие – 3-tier: Уровень представления никогда независимо не работает с данными, только через уровень логики (линейная топология) – MVC: Все уровни могут взаимодействовать непосредственно (треугольная топология) Использование – 3-tier: В основном используется для Web приложение, где клиент, middleware и слой данных расположены на физически раздельных платформах – MVC : Исторически применяется для запуска всех компонент на одной рабочей станции (однако часто применяется и для распределённых систем)