Алексей КПо сравнению с сетевым пингом затратами на ORM как правило можно принебречь.
я вас не очень понял, т.е. создание объектов ORM, маппинг это фигня, а создать экземпляр класса и преобразовать к интерфейсу - это долго?

Алексей КНормальный кодогенератор + ORM уже сам по себе является универсальным репозитарием на все случаи жизни. Лепить поверх этого ещё одну абстракцию глупо
глупо дублировать код, глупо полагатся на пафосные экстрасенсорные способности (предвидеть абсолютно все ситуации), глупо ставить себя в зависимость от некоторой конкретной реализации, которую в будущем возможно придется заменить более современным/надежным/подходящим средством, и покажите мне человека, который знает (т.е. сталкивался на практике) абсолютно все плюсы и минусы, возможности основых используемых ORM, это же ведь ему позволит сделать правильный выбор

SolYUtor90% кода по работе с бд используется один раз. Остальное можно запихнуть в QueryObject.
Алексей КГде я предлагал дублировать код?
собственно предлагали в том месте, где надо избавиться от абстракции с репозиторием
что насчет выборки с джоинами, в двух местах программы, с разными условями where
что насчет сохранения объектов из двух мест с какой-то пред-обработкой

SolYUtorС нетерпением жду вашего рассказа, как вы легко и просто, потратив полдня замените свою реализацию на MongoDB.
как нибудь посмотрю что это

SolYUtorЭто называется опыт. Предвидеть необходимость постраничной выборки ( и ограничений на размер выборки в общем) - не ахти какое знание.

вы умеете абстрагироваться? это был элементарный пример, а ситуаций бывают разные

Алексей КЭто к тому, что сам факт использования ORM мало влияет на производительность. Вопрос в том как он используется.

все равно не очень понятно, использовать ORM напрямую, либо создать класс/интерфейс обертку и обращаться к ORM внутри - где здесь заметное уменьшение производительности, создание экземпляра? преобразование к интерфейсу? лишний уровень в стеке вызовов? это все становиться заметным по сравнению с сетевым пингом? можно пример?

Алексей КНамерено идти по пути "N+1 запрос

хм, не знаю как в MongoDB, в EF есть Include, а в гибернейте Fetch, все спокойно достается заранее и то что требуется, отсоединяется и возвращается, интересно стало как в сервисной архитектуре вы будете через xml передавать отслеживаемые сущности
с кэшем второго уровня тоже не понятно, насколько я понял у вас был какой-то дикий пример, который вы забыть не можете, это относится к сетевому пингу?

SolYUtorЭто называется опыт.

Алексей КПросто надо иметь некоторый кругозор, не более того.

кругозора мало, чтобы не ударить в грязь лицом в любой ситуации, нужны глубокие знания, вплоть до того, что EF упадет при обработке 32561 записи в одной транзакции
с опытом приходит только часть, прикиньте самостоятельно сколько проектов надо сделать, чтобы всесторонне попробовать каждую возможность хотя бы одного инструмента, и сколько времени надо на это потратить, экстрасенсом быть выгодней