blest1) Правильно ли я все понимаю схему

Если под «правильно» понимается «мы дважды дублируем данную сущность», то нет. Ибо, что такое сущность? Табличка в базе данных? Сущность в контексте репозитория / ORM, отражает то, как данные хранятся, немного скрывая свою реляционную природу. В теории, сущности могут лежать вовсе не в реляционной структуре, а в какой-нибудь NoSQL, или ещё где-то, и нам это должно быть не важно. Но это всё лирика, и лежит в плоскости более практичной — мы прекрасно знаем где и как данные будут лежать, всё что слой доступа к данным делает, это типизирует эти данные, ну и немного (совсем немного), скрывает конкретику природы хранилища. Т.е. MS SQL мы можем заменить на какой-нибудь Oracle, и это должно прокатить.

А под DataModel понимается скорее всего DTO — это конкретные кортежи данных, которые вовсе не обязаны соответствовать табличкам. Например, у тебя есть некий грид и 10 колонок, чтобы их получить, надо собрать данные из 5 таблиц, вот и выбирай: либо 5 сущностей, либо 1 DTO. А как 5 сущностей превратить в 1 DTO? Ответ — проекция, чувак. Проекция! :)

В общем, ответ на первый вопрос: скорее нет, чем да.

blest2) допускается ли наследование DataModel От Entity или лучше независимые классы создать

Нет! Не допускается. Даже не вижу смысла отвечать на вопрос «почему?», ведь эти классы служат совершенно разным целям и решают разные задачи.

blest3) Всегда ли придерживаться данной модели даже для небольших проектов или можно пропускать некоторые элементы (скажем DataModel можно не использовать) - по феншую

Можно со временем состряпать свой некий bootstrapper, который будет содержать каркас, с которым удобно работать. Если каркас получился удачным, то большая часть предметной области может в него удобно лечь. Ну а это уже приходит с опытом. Ну и задачи со временем становятся довольно таки однотипными.

kmawhVosttМожно со временем состряпать свой некий bootstrapper

ViPRos

Нет, ВИПРОС это очердной замес на тему вечного двигателя и серебряной пули.

Типа.

А что, если нам заморочиться, и сделать такую волшебную хренобазу, в которой всё при всё создаётся без участия программистов? Сущности? Определяются на уровне данных, клац по кнопке, определил поля -- и готово! А вся при вся бизнес-логика тоже определяется на уровне данных, клац по кнопке, определил некий Workflow -- и готово! Вот сделать это всё и разогнать всех программистов к чёртовой матери. Путь идут пасутся, так как программисты больше не нужны. Нужен лишь один ВИПРОС и талмуд. =)

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

Так что всё впереди, готовьтесь программеры, ваш век подходит к концу

kmawпредпочитаю, чтобы репозитории возвращали и принимали только DTO, чтобы дальше репозиториев Entity не выходили

репо получает и отдаёт Entity, DTO получают/отдают дата-сервисы, иначе репо быстро превратится в God Object и потянет на себя бизнес-логику, чего категорически надо избегать.

у репы банальная, и тупейшая в мире задача -- скрыть от остальной части ПО способ доступа к данным, Entity это у же и есть по сути DTO, только между миром БД и внутренней кухней ПО. зачем городить огород?

DTO хороши, чтобы отдавать только то, что нужно. например, в Entity может быть сотня полей, плюс связи всякие. а сервису нужен только десяток и чуток полей из связей.

сервису нафиг не упало получать отмаппленный по все помидоры Entity со всей сотней полей. для чего? ублажить Идею супер-мега-слоёного разделения? в погонях за красивыми картинками и схемками, люди частенько отдаляются от реальности и реальных задач примерно на пару парсеков.

kmawтакой вариант, наверное, для самых простых справочников "Id Name" годится

глупости какие-то, ты меня не услышал, но я повторю:

задача репо -- скрыть способ доступа к данным от остальной части ПО. репо великим русским языком -- это ХРАНИЛИЩЕ. а хранит он там Entity. соответственно, в задачи репо входит отдавать и принимать Entity, а не какие-то там DTO.

поверх репо пилится дата сервисы (для анемичной модели данных), которые уже принимают и отдают DTO, и ПО работает с дата сервисами. да, Entity в идеале за пределами дата сервисов уже не видна.

резюмирую: не надо сваливать на репо то, чем он не должен заниматься. репо не обязано знать ни о каких DTO, не должно заниматься маппингом и прочим. у него маленькая область ответстенности, и не надо на него сваливать что-то там ещё.

kmawт.е. так должен выглядеть репозиторий?

да, примерно так.


kmawтогда нафиг он нужен

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