Более быстрые запросы которые просто отдают данные для отображения и при этом полнофункциональная доменная модель для команд. Очень, знаете ли неудобно, когда для отображения грида в котором 3-4 колонки со значениями, для каждой строки приходится загружать весь агрегат целиком.
При этом query модель вообще не позволяет апдейтить сущности в хранилище, и поэтому нельзя испортить консистентность данных сохранив не прошедшие валидацию доменом значения.
Архитектура ASP.NET WebForms с событиями гораздо менее естественна для веба чем для толстых windows приложений. Контрольный вопрос вам:
Когда происходит событие в WebForms?
Как так получается, что если зарегистрироваться на ваш курс, он отображается в текущих курсах, хотя начнется он только 26 января? Что-то не то с настройками курса.
Это типичный функциональный список. Он же односвязный список. Представляет собой всегда голову (то есть первый элемент и хвост — такой же список только без первого элемента). По идее, он генерик, какого реально типа определяется type infering по использованию.
Нет у гуид повышенной устойчивости к перебору. Особенно у Sequential. Если вам нужна криптографическая стойкость, нужно использовать другие алгоритмы. А следующий гуид вполне можно предсказать.
Бтв, в рамках паттерна, может так получится, что команда выполнилась, а а ее результат пока в отображение не попадает (например, комментарий не прошел премодерацию) и в этом случае вариант когда вы пытаетесь по Id загрузить комментарий упадет с ошибкой.
Парадигма DDD оперирует понятием агрегат и корневая сущность агрегата. И грузит из базы агрегат целиком. Это необходимо чтобы вся бизнес логика энкапсулированная внутри классов агрегата применялась верно. Для отображения данных это излишне, собственно отсюда и родился паттерн CQRS.
Значит перегрузить дерево комментариев от того коммента на который отвечаем. Ну либо сделать над собой усилие и сгенерировать уникальный идентификатор на клиенте.
А автор не вкладывал сюда значение «плоский». Он вкладывал значение обычный (то есть не навязанный никаким фреймворком). При этом если доменная модель предполагает для конкретного объекта наследование — наследование будет, просто это наследование должно быть по причине такого домена, а не потому что наш фреймворк требует чтобы все сущности были отнаследованы от абстрактного класса Component.
Если переводить пословно получится что-то типа
«Обыкновенный старый C# объект». Но, учитывая что вводилось это понятие как клевое название для обычных классических объектов, перевод «Старый добрый C# объект» тут вполне в тему и звучит более по-русски
Простите, но все три определения ввел в обиход Мартин Фаулер. И он в них вложил вполне определенный смысл. POCO — если переводить на русский «Старый добрый C# объект» объекты в объектно-ориентированном программировании содержат не только данные но и поведение.
При этом query модель вообще не позволяет апдейтить сущности в хранилище, и поэтому нельзя испортить консистентность данных сохранив не прошедшие валидацию доменом значения.
Когда происходит событие в WebForms?
Но без паттерн матчинга работать с ним не удобно.
«Обыкновенный старый C# объект». Но, учитывая что вводилось это понятие как клевое название для обычных классических объектов, перевод «Старый добрый C# объект» тут вполне в тему и звучит более по-русски