Индивидуальные и групповые автопоилки: для животных. Схемы и конструкции...
Особенности сооружения опор в сложных условиях: Сооружение ВЛ в районах с суровыми климатическими и тяжелыми геологическими условиями...
Топ:
Комплексной системы оценки состояния охраны труда на производственном объекте (КСОТ-П): Цели и задачи Комплексной системы оценки состояния охраны труда и определению факторов рисков по охране труда...
Проблема типологии научных революций: Глобальные научные революции и типы научной рациональности...
Выпускная квалификационная работа: Основная часть ВКР, как правило, состоит из двух-трех глав, каждая из которых, в свою очередь...
Интересное:
Лечение прогрессирующих форм рака: Одним из наиболее важных достижений экспериментальной химиотерапии опухолей, начатой в 60-х и реализованной в 70-х годах, является...
Наиболее распространенные виды рака: Раковая опухоль — это самостоятельное новообразование, которое может возникнуть и от повышенного давления...
Аура как энергетическое поле: многослойную ауру человека можно представить себе подобным...
Дисциплины:
2020-11-03 | 134 |
5.00
из
|
Заказать работу |
|
|
Требования
• Информация может быть представлена по-разному и в нескольких местах для разных пользователей.
• Изменения в данных должны немедленно отображаться в различных представлениях.
• Простота изменения интерфейса, даже прямо во время работы приложения.
• Перенос интерфейса между платформами не должны влиять на код, связанный с методами работы с данными и структурой данных приложения.
Группы классов
Модель реализует основные операции доступа и управления данными и бизнес-логику, возможность регистрировать зависимые от него обработчики и представления (наблюдателей). При изменениях все зарегистрированные компоненты.
Представление представляет данные в некотором виде, читая их из модели при инициализации и после сообщений о произошедших изменениях. Кроме того, представление инициализирует связанный с ним контроллер.
Контроллер обрабатывает действия пользователя, транслируя их в операции над моделью или показ представлений.
Архитектура MVC: Сценарий инициализации системы и обработки действий пользователя.
Основные шаги реализации
• Выделить структуру данных, с которыми система работает, и набор операций над ними.
• Реализовать механизм передачи изменений.
• Реализовать необходимые представления.
• Реализовать необходимые обработчики действий пользователя.
• Спроектировать и реализовать связь между обработчиком и представлением.
• Реализовать построение системы из компонентов и их инициализацию.
Дополнительные аспекты реализации:
• Динамические представления.
• Инфраструктура и иерархия представлений и обработчиков.
• Повысить переносимость за счет отделения компонентов от конкретных библиотек и платформ.
|
Недостатки
• Возрастание сложности разработки.
• Потери в производительности из-за необходимости обработки запросов пользователей сначала в обработчиках, затем в моделях, а затем во всех обновляемых компонентах.
• Представления, модели и обработчикипочти никогда нельзя переиспользовать по отдельности.
28. Архитектура MV*:
Архитектура Model View View-Model.
Сервис-ориентированная архитектура. 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
|
|
Своеобразие русской архитектуры: Основной материал – дерево – быстрота постройки, но недолговечность и необходимость деления...
Организация стока поверхностных вод: Наибольшее количество влаги на земном шаре испаряется с поверхности морей и океанов (88‰)...
Типы сооружений для обработки осадков: Септиками называются сооружения, в которых одновременно происходят осветление сточной жидкости...
Двойное оплодотворение у цветковых растений: Оплодотворение - это процесс слияния мужской и женской половых клеток с образованием зиготы...
© cyberpedia.su 2017-2024 - Не является автором материалов. Исключительное право сохранено за автором текста.
Если вы не хотите, чтобы данный материал был у нас на сайте, перейдите по ссылке: Нарушение авторских прав. Мы поможем в написании вашей работы!