Архитектура MVC: Структура классов

Требования

• Информация может быть представлена по-разному и в нескольких местах для разных пользователей.

• Изменения в данных должны немедленно отображаться в различных представлениях.

• Простота изменения интерфейса, даже прямо во время работы приложения.

• Перенос интерфейса между платформами не должны влиять на код, связанный с методами работы с данными и структурой данных приложения.

Группы классов

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

Представление представляет данные в некотором виде, читая их из модели при инициализации и после сообщений о произошедших изменениях. Кроме того, представление инициализирует связанный с ним контроллер.

Контроллер обрабатывает действия пользователя, транслируя их в операции над моделью или показ представлений.

Архитектура MVC: Сценарий инициализации системы и обработки действий пользователя.

Основные шаги реализации

• Выделить структуру данных, с которыми система работает, и набор операций над ними.

• Реализовать механизм передачи изменений.

• Реализовать необходимые представления.

• Реализовать необходимые обработчики действий пользователя.

• Спроектировать и реализовать связь между обработчиком и представлением.

• Реализовать построение системы из компонентов и их инициализацию.

Дополнительные аспекты реализации:

• Динамические представления.

• Инфраструктура и иерархия представлений и обработчиков.

• Повысить переносимость за счет отделения компонентов от конкретных библиотек и платформ.

Недостатки

• Возрастание сложности разработки.

• Потери в производительности из-за необходимости обработки запросов пользователей сначала в обработчиках, затем в моделях, а затем во всех обновляемых компонентах.

• Представления, модели и обработчикипочти никогда нельзя переиспользовать по отдельности.

28. Архитектура MV*:

Архитектура Model View View-Model.

• Двухсторонняя коммуникация с представлением;
• Свойства представления совпадают со свойствами View-модели
• Один экземпляр View-модели связан с одним отображением.

Сервис-ориентированная архитектура. REST -сервисы.

Сервис-ориентированная архитектура: SOAP, REST.

Описывает приложения, предоставляющие и потребляющие функциональность в виде сервисов с помощью контрактов и сообщений через интерфейсы, областью действия которых является приложение, а не компонент или объект.

REST

В технологии передачи репрезентативного состояния (Representational State Transfer, REST), как и SOAP, используется протокол HTTP.

Основная идея – назначение уникального идентификатора URL каждой веб-службе, каждому ресурсу.

Ресурс — это любая сущность, на которую клиент может поставить ссылку или с которой может попытаться взаимодействовать

Каждый ресурс должен и иметь URI.

Параметры веб-службе передаются как параметры форм.

Каждая веб-служба отображается в один из методов протокола HTTP.

Представление ресурса — это любая полезная информация о состоянии ресурса.

Ресурсы должны быть связаны максимально сильно связаны друг с другом (как вершины графов).

Основной принцип проектирования REST

REST предлагает разработчикам использовать HTTP-методы явно в соответствии с определением протокола. Этот основной принцип проектирования REST устанавливает однозначное соответствие между операциями create, read, update и delete (CRUD) и HTTP-методами. Согласно этому соответствию:

1     Для создания ресурса на сервере используется POST.

2     Для извлечения ресурса используется GET.

3     Для изменения состояния ресурса или его обновления используется PUT.

4     Для удаления ресурса используется DELETE.

Каждый HTTP-запрос происходит в изоляции от других, так как серверу никогда не приходится отслеживать запросы, выполненные ранее.

Пример REST запроса

POST /users HTTP/1.1

Host: myserver

Content-Type: application/xml

<?xml version="1.0"?>

<user>

<name>Robert</name>

</user>

HTTP-запрос POST используется корректно, а тело запроса содержит полезную нагрузку. На принимающей стороне в запрос может быть добавлен содержащийся в теле ресурс, подчиненный ресурсу, определенному в URI запроса

Хорошим тоном является использование хотя бы основных HTTP кодов ответов.

Фильтрация

GET /books?color=red

Сортировка

GET /books?sort=-year,+name