Сервер приложения облачного SaaS приложения

Сервер приложения организованный в соответствии с архитектурным паттернам сетью состоит из 3 подсистем:

1. Определяет обработку данных приложения (сохранение, использования). Сервер приложения содержит отдельную модель для каждого типа обрабатываемых сущностей. Пусть есть служба courses ориентирован на обслуживания перечня учебных курсов, для которой достаточно присутствие лишь одной модели курсов. Так как модели работаю с данными приложения, то содержат средства взаимодействия с уровнем сохранения.

2. Создают презентации для пользователей и содержат сведения о моделях, интересующих пользователей. Представление служит интерфейсом между пользователем и ее данными. В службе courses есть только один вид модели, но она связана с различными представлениями (просмотрам всего, вывод по какому-нибудь курсы или дополнительные представления).

3. Контроллеры – связующе звено при организации взаимодействия в двух направлениях: если пользователь хочет взаимодействовать с представлением. Если пользователь что-то нажимает, то вызывается действие определённого контролер, который выполняет преопределённую функцию. Каждый контроллер соответствует одной модели и может запросить модель для получения или изменения информации. Взаимиост от запроса, в контроллер определения представления и применят его с необходимой информацию. Пусть службы corsres состиот из одной модели, приложение содержит только один контроллер. Действие осуществимое этим контроллером позволяет обрабатывать любой тип взаимодействия пользователя с представлением курса. Контроллер реализует бизнес-логику получения данных от моделей выбором конкретной формой представления курса.

Система взаимодействия рисунок

Браузер отправляет запрос (1). Контроллер взаимодействует с моделью (обмен данных) и взывает представление. В результате представление выводит экран браузера

Лекция 6

Исходя из того, что SaaS приложения всегда ориентированы на представления и всегда полагаются на слой сохранения, выбор фактора эмиссии представляется логичным.

Обобщенная структура рисунок

Каждый контроллер взаимодействует с своей моделью и своим представлением. Данная схема автоматически генерируется средой разработкой RES и Javascript. Среда разработки PHP создает серверы на основе паттернов FMLKU?? Который группирует структур вокруг представления, а модели вставляют ограниченный динамический контент страниц представления подразумевается, что контроллер уже встроен в среду разработки. По схеме можно разработать сайт погоды.

Паттерн Page контрллер который используется в среде сенатор на языке Ruby. Подходит для приложений, которые компонуются в виде малого числа отдельных страниц. Данный паттерн придает каждой странице свой простой контроллер, который умеет лишь генерировать страницы.

Приложение, которое создает для пользователя последовательность страниц, по нескольким моделям целесообразно использовать паттерн front контроллер. В данном паттерне предусматривается, что один контроллер обрабатывает все входящие запросы. Обработка запросов отдельным контроллером для каждой модели полностью исключается. Этот подход применяется в сервлетах в рамках Java 2 Enterprise Edition (J2EE), где один контроллер использует методы из различных моделей для генерации одного из набора представлений.

Таким образом, паттерн MBS выделят модели (реализует бизнес логику, представления (отображают информацию для юзеров) и контроллер (обеспечивают взаимодействие между представлениями и моделью). Каждое действие пользователя на веб странице, обрабатывается каким-то контроллером действия. Данная форма организации удобна для интерактивных Saas приложений с различными типами модели, где имеет смысл применяет смысл контроллер и представление для каждого типа модели. Обработка HTTP запрос в веб браузер. Запрос состоит из HTTP метода (get и т.д.) и URL, метод задает действие контроллера, а URI адрес – ресурс, к которому применяется данное действие. Отображения входящего запроса на действие контроллера – это маршрутизация, а его итог маршрут. Наиболее эффективно и простая маршрутизация при использовании REST подхода. Встроенаня поддержка для REST маршрутизации предполгается по умолчанию.

Операция над ресурсом	HTTP метод	URI	Действие контроллера
Индекс (список всех курсов)	GET	/courses	Index
Чтение (отображение конкретного курса)	GET	/courses/:id	Show
Отображение формы для создания нового курса	GET	/courses/new	New
Создание нового курса по заполненной форме	POST	/courses	Create
Отображение формы для редактирования существующего курса	GET	/courses/:id/edit	Edit
Обновление курса по заполненной форме	PUT/PATCH	/courses/:id	Update
Удаление существующего курса	DELETE	/courses/:id	Destroy

Действие контроллера курса должно быть вызвано, когда входящий запрос соотвествует данному URI и HTTP методу. Отображение маршрутов действие контроллера базируется на соглашении по конфигурации, которое принято в SaaS приложении и могут настраиваться. В URI курсы/:id те сегменты, которые начинаются с: - параметры маршрута, а id представляет собой атрибут, первичный ключ экземпляр модели. Например, маршрут get/курсы/7 – это вторая строка таблицы с: id который имеет значение 7. Поэтому, запрос отображает детали курса чей идентификатор курса есть 7, если существует. Маршрут \get – первая строка, запрашивает список всех курсов, post\курс – 4-ая строка, создает новую сущность для курсов БД. Идентификатор не указывается, так как новый курс не будет иметь идентификатор, пока не будет создан. Действие, index и create имеют одинаковый URI, но разные http методы, что делает их различными маршрутами. REST интерфейс упрощает работу с сервисное ориентированной архитектурой, так как если каждый запрос является самодостаточный, взаимодействие между службами устанавливать не нужно и возможно полагаться на концепцию текущей сессии, что и делает SaaS приложения при взаимодействие с юзером через веб браузер.