skyANAПравильно-ли я понял, что для маппинга ты используешь AutoMapper?

Да, всё верно. До недавнего времени у проекций был существенный недостаток: в проекцию нельзя было передать параметры. Теперь всё в шоколаде, параметры можно передавать

skyANAЯсно. .Project() и .To<>() - это методы расширения из библиотеки AutoMapper.

Точно.

skyANAhVostt, погоди, то есть если "для изменяющих запросов, берутся Entity", то получается мы не просто выбираем данные, но ещё и пропускаем их через AutoMapper?

Нет, просто Entity берутся. Но можно изменять и проекции, они также мапятся в Entity обратно -- способ очень хорошо подходит для Angular-style разработки (но мне всё равно не нравится, теряется контроль).

skyANAИ они маппятся сами на себя?

Поясни плз, что ты имеешь сейчас в виду? Кто на кого мапится?

Есть ORM Entity (EDM), а есть проекции (DTO). Для изменения берём Entity, для отображения/передачи DTO. Но можно работать только с DTO, на этом можно полностью построить архитектуру (когда напрямую с Entity больше никто не работает).

skyANAКод в случае с Entity как выглядит?
Так:

?

Зачем???

Просто берём Entity, без всякого AutoMapper-а. Тем более проекция Entity -> Entity приведёт к bulk include всех навигационных параметров. Это практически никогда не нужно (лично я с такой необходимостью даже не сталкивался).

skyANAА если есть полноценный DomainModel объект, не DTO, и не ORM Entity, то свой велосипед изобретать?

Как раз таки нет. DomainModel «объект» это и не объект вовсе. Это может быть целое состояние, с разными данными. И совсем не обязательно оно должно быть полностью загружено со всем потрохами. В ином случая, я бы не добавлял такую сущность (если по-твоему это и правда именно объект), ибо лишнее. Как тама говорил Оккама?

skyANAИ как код будет выглядеть у тебя в этом случае?

Например, Get(id)


skyANAНу что значит "не объект вовсе". В домене определён некий тип (класс), экземпляр этого класса - есть объект. Объект имеет состояние и поведение.

И это не по-моему, это ООП :)

Ну ладно, есть у тебя некий объект, и как он у тебя хранится? По кускам вразброс по базе? И чем это не отражение? Или у него есть ещё какие-то поля/данные, не имеющие прямого отношения к данным в хранилище? Я предпочитаю мыслить в контексте задачи, а сейчас о чём ты говоришь, я не понимаю.

skyANAhVostt, ну мы же рассматриваем некий универсальный, по-твоему мнению, механизм. Вот и хочется понять степень его универсальности :)

Ты механизм предложенный мною для извлечения данных зачем экстраполируешь на DDD? Так мы скоро до UX доберёмся, а затем до маркетинга, затем до теории большого взрыва.

ПарамонhVosttИменно, я преподношу их как универсальный механизм -- для чего? Отвечаю -- для выбора нужного среза данных. Что такое проекция? Это POCO объект с нужным набором полей, может включать в себя поля из одной или нескольких ORM Entity, целые объекты
Эти проекции получается часть модели? Затем проекции мапятся во viewmodel?
hVosttвычисляемые поля и аггрегации.

Могут содержать логику?

Зависит от задачи. Как я уже неоднократно говорил, мы изготавливаем ПО различного уровня сложности, для самых различных применений. У нас нет одной единственной серебяной пилюли, одного универсального решения для всех задач.

Делали CRM, у нас было несколько слоёв, с максимальным разделением ответственности. Делаем небольшую службу маленьким REST для периодического дёргания из вне -- зачем мы будем корячиться и убивать ресурсы на сложную ветвистую архитектуру?

По вопросам skyANA упорно складывается ощущение, что он думает мы один единственный проект уже 10 лет пилим, как у них. И поэтому взаимопонимания не случается. Это прискорбно.

ПарамонЭти проекции получается часть модели? Затем проекции мапятся во viewmodel?

И всё же отвечу. Проекции могут как мапиться во вьюмодель, так и сами выступать конечным контейнером для данных. В случае OData это именно так. Зависит от общей концепции архитектуры. Основной, принятый принцип должен соблюдаться повсеместно, это важно для сопровождения и развития продукта.

ПарамонМогут содержать логику?

Нет, не могут. Логику содержит сам механизм проекции -- это логика, но не объект, хранящий проекцию. Поэтому проекции не относятся к слою доступа к данным.

skyANAА о вас я думаю, что вы попробовав разные варианты в разных проектах, пришли на данный момент типа к вот такому универсальному.
Пока оно тебе видится идеальным. Но вот наверняка есть вероятность того, что за год ты накопишь негативного опыта и перепишешь в какой-то другой вид.

А я и не утверждал обратного Даже пол года назад я думал немного иначе.

skyANAhVosttУ нас нет одной единственной серебяной пилюли, одного универсального решения для всех задач.Хм. Вот теперь всё понятно. Пришли к очевидному выводу: разные задачи - разные реализации.

Я уже столкнулся с кодом, написанным «под копирку» независимо от задачи. Хорошего мало. Единожды усвоенный урок некими специалистами потом использовался как единственно возможное решение. Кое что пришлось на корню переписывать.