Command and Query Objects — архітектурний шаблон проєктування заснований на принципі CQRS
Переваги та недоліки
Переваги
бізнес-логіка поділяється між об'єктами queries і commands. Код сценарію використання інкапсульований в обробнику обробники не містять зайвих залежностей легко реалізовувати наскрізну функціональність, оскільки всі обробники мають однаковий інтерфейс queries відповідають лише за читання даних, commands — за зміну даних. Зменшується навантаження на вибірку даних легко замінити компоненти. Їх регулюванням займається посередник
Недоліки
важкий в реалізації збільшується кількість класів
Опис мовою C#
Додамо деякі класи, які будуть симулювати реальні об'єкти.
Запишемо інтерфейс query та її обробника. Інтерфейс не містить ніяких визначень. Його будуть реалізовувати дто-класи призначення яких інкапсулювати дані, та передати їх обробникам. Іншими словами, query відіграє роль аргументів функції. Зате, він містить очікуваний результат повернення, таким чином на його обробника накладаються певні обмеження. Обробник для query — — містить лише один метод — . Він приймає аргументи, та повертає необхідний результат.
Припустимо, що виникла задача, знайти користувачів, за введеним значенням. Тоді Query і обробник можуть мати наступний вигляд:
Деколи немає необхідності в породжені великої кількості класів обробників, тоді можна помістити всі обробники в один клас:
Залишилось написати клас, який буде спідставляти для query його handler.
Використання матиме наступний вигляд:
Розробка command має ту саму структуру. Тільки призначенням command буде не взяття даних, а їх модифікації, створення, видалення тощо.
Див. також Шаблони проєктування програмного забезпечення Об'єктно-орієнтоване програмування CQRS
Джерела A Simple CQRS Pattern Using C# in .NET On the query side of my architecture