'

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

Понравилась презентация – покажи это...





Слайд 0

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


Слайд 1

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


Слайд 2

Независимость данных в реляционной СУБД Отделение представления от логики и данных


Слайд 3

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


Слайд 4

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


Слайд 5

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


Слайд 6

N-уровневая архитектура


Слайд 7

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


Слайд 8

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


Слайд 9

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


Слайд 10

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


Слайд 11

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


Слайд 12

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


Слайд 13

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


Слайд 14

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


Слайд 15

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


Слайд 16

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


Слайд 17

Шаблоны проектирования Design Patterns


Слайд 18

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


Слайд 19

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


Слайд 20

Происхождение Шаблонов Проектирования 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”, 1994. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Сейчас шаблоны проектирования широко используются в разработки коммерческих приложений


Слайд 21

Шаблон проектирования MVC


Слайд 22

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


Слайд 23

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


Слайд 24

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


Слайд 25

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


Слайд 26

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


Слайд 27

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


Слайд 28

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


Слайд 29

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


×

HTML:





Ссылка: