Архитектура Web приложения презентация

хранения

То что видит пользователь

Таблицы и ссылки

Файлы на диске

Каждый уровень не зависит от уровня ниже

уровень

Физический уровень

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

Нужно всегда отделять представление - VIEW (то что видит пользователь) от модели- MODEL (данных сервиса)

разделить компоненты на разные уровни (слои):
Физическое разделение
Логическое разделение

происходят на одной машине
Представление, логика, уровень данных сильно связаны
Расширяемость (Scalability): на одном процессоре можно запустить только ограниченное число процессов
Переносимость (Portability): для перемещения на новую машину придётся переписать весь код
Поддержка (Maintenance): при изменении одного слоя придётся изменять остальные

Data Base

Presentation Logic

Business Logic

Data Access Logic

Приложение

базу данных
Отделение представления от данных
Высокая нагрузка на сервер
Потенциальные проблемы с задержкой в сети
Уровень представления и логики остаются сильно связанны

Business Logic

Presentation Logic

Data Access Logic

Data Base

Data Layer

Client

Server

и данные разделены

Presentation Layer
Содержит
Presentation Logic

Business Layer
Содержит
Business Logic

Data Layer
Содржит
Data Access Logic

Data Base

Client

Server

DB Server

год

Сложить всех клиентов вместе

Запрос

Клиент 1
Клиент 2
Клиент 3
клиент 4

База данных

Хранилище

Уровень представления

Уровень логики

Уровень данных

Принципы архитектуры:
Клиент-серверная архитектура
Каждый слой (данные, представление и логика) не зависит от остальных и не зависит от реализации
Несоединённые слои вообще никогда не взаимодействуют
Изменение платформы влияет только на тот уровень который на ней находится

год

Сложить всех клиентов вместе

Запрос

Клиент 1
Клиент 2
Клиент 3
клиент 4

База данных

Хранилище

Уровень представления

Уровень логики

Уровень данных

Предоставляет графический интерфейс
Обрабатывает пользовательские события
Иногда называют GUI или client view of front-end

год

Сложить всех клиентов вместе

Запрос

Клиент 1
Клиент 2
Клиент 3
клиент 4

База данных

Хранилище

Уровень представления

Уровень логики

Уровень данных

Набор правил для работы с данными
Может обрабатывать запросы нескольких пользователей
Иногда называют middleware или back-end
Недолжен содержать пользовательских форм или непосредственно обращаться к данным

год

Сложить всех клиентов вместе

Запрос

Клиент 1
Клиент 2
Клиент 3
клиент 4

База данных

Хранилище

Уровень представления

Уровень логики

Уровень данных

Физическое хранилище для данных (persistence)
Управляет доступом к БД или файловой системе
Иногда называется back-end
Недолжен содержать пользовательских форм или бизнес логики

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

хорошо делится и поэтому может быть быстрее решена (уровни можно разрабатывать параллельно)
Web дизайнер делает уровень представления
Инженер (Software Engineer) делает логику
Администратор БД делает модель данных

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

Нужно одно общее и многоразовое решение: Шаблоны проектирования

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

by Beck and Cunningham (1987)
Popularity in CS after the book: “Design Patterns: Elements of Re-useable Object-oriented software”, 1994. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
Сейчас шаблоны проектирования широко используются в разработки коммерческих приложений

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

нескольким представлениям разделять одни и те же данные
Сделать подожку нескольких клиентов (клиентских частей приложения, представений) проще

с текстом или БД) отделено от представления (график или список) и того как данные будут обрабатываться (GUI или командная строка)

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

зависит от представления
Одна модель для нескольких представлений
Представление
Представляет данные пользователю
Позволяет пользователю производить действия
Не обрабатывает ничего самостоятельно
Контроллер
Описывает как реагирует интерфейс на события пользователя
Получает сообщения от представления
Взаимодействует с моделью (Говорит что за данные следует показывать)

сервера (JSP)
Контроллер
Клиентские скрипты
Процесс обработки http
Бизнес логика

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

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