Command Query Responsibility Segregation

Скачать презентацию на тему: "Command Query Responsibility Segregation" с количеством слайдов в размере 24 страниц. У нас вы найдете презентацию на любую тему и для каждого класса школьной программы. Мы уверены, что наши слайды помогут найти вам свою аудиторию. Весь материал предоставлен бесплатно, в знак благодарности мы просим Вас поделиться ссылками в социальных сетях и по возможности добавьте наш сайт MirPpt.ru в закладки.

Нажмите для просмотра
Command Query Responsibility Segregation

1: Command Query Responsibility Segregation ИЛИ ПРОСТО ЦЭКУЭРЭС

2: Но для начала выкинем R из CQRS CQS – Command Query Separation, разделение команд и запросов Основная идея CQS заключается в том, что любые методы могут быть только двух типов: - Queries – возвращают результат, не изменяя состояние объекта - Commands - изменяют состояние объекта, не возвращая значение

3: Не-CQS-ный код

4: Превращается в CQS-ный код

5: А вот теперь CQRS CQRS – Command Query Responsibility Segregation, разделение ответственности на команды и запросы Та же идея, что и в CQS, но на более высоком уровне – на уровне всей системы Для изменения состояния системы используем Command Для выборки данных о состоянии системы используем Query

6: CRUD-сценарий

7: Что происходит дальше? - У нас есть концептуальная модель, которая взаимодействует с основными объектами нашего домена - Мы стараемся сделать наше хранилище наиболее приближенным к нашим данным - Нам требуется выбирать и отображать все более сложно связанные данные, в том числе отчеты - Наши объекты становятся все более сложными с большим количеством вспомогательных полей - Вслед за объектами усложняется и хранилище - Появляется лишнее для команд, нужное только для запросов

8: CQRS-сценарий

9: CQRS-сценарий с разными хранилищами

10: Эволюция команд и запросов на практике Акт первый

11: Эволюция команд и запросов на практике Акт второй

12: Эволюция команд и запросов на практике Акт третий

13: Эволюция команд и запросов на практике Акт четвертый

14: Эволюция команд и запросов на практике Занавес - Меньше зависимостей в каждом классе - Соблюдается принцип единственной ответственности - Маленький класс проще заменить - Маленький класс проще тестировать - В целом дизайн кода однотипный и понятный - При расширении функциональности системы сложность дизайна растет почти линейно

15: CQRS может быть на любом уровне Тенденция рефакторинга: - Растет количество классов - Растет количество методов в каждом классе - Растет количество зависимостей каждого класса - Разбиваем их на Command и Query Вместо больших классов с множеством зависимостей мы движемся в сторону большого количества маленьких однотипных классов, каждый из которых отвечает за единственное бизнес-правило

16: Наш недо-CQRS

17: Наш недо-CQRS

18: Наш недо-CQRS

19: Наш недо-CQRS

20: Наш недо-CQRS

21: Наш недо-CQRS

22: Как это выглядит в бою?

23: Как это выглядит в бою?

24: Почему недо-CQRS? Работа по большей части с CRUD При выполнении команды хочется тут же получить какой-то результат и использовать его для отрисовки UI После добавления элемента часто необходимо перенаправить пользователя на страницу с только что добавленным элементом Мы изменяем поля CommandContext-ов, мы сожалеем

Скачать презентацию


MirPpt.ru