О сущностях, DTO, ORM и Lazy Load

[@amazed]

Если в агрегате слишком много данных, это может свидетельствовать о проблемах с проектированием. Типичные корни агрегации — корзина, заказ, посылка. Люди обычно не работают с данными из тысяч строк, поэтому загрузка всей связанной коллекции может быть не самой производительной, но не смертельной операцией.

Что если речь идет о более сложных системах, автоматизирующих некие функции управления, производства, проектирования? Тогда ситуация с загрузкой графа из большого количества сложно связанных объектов становиться типичной.
Здесь все выглядит иначе.
1. Вариант «загружать все» бывает довольно хорошим решением.
2. Сущности нужно загружать потому, что если пользоваться SQL, программисту придется писать неимоверное количество лишнего кода. Ленивая загрузка сущностей обеспечивает разработчику ощущение, что все объекты просто есть в памяти и позволяет сосредоточиться на решении задачи и писать более понятный код.
3. На начальном этапе разработки ленивая загрузка может сильно тормозить, но когда все уже работает, легко можно перебрать код и добавить запросы, вовремя поставляющие данные алгоритму так, чтобы исключить ленивую загрузку вообще и минимизировать количество обращений к базе. Эту задачу можно решать независимо от реализации самого алгоритма.
4. Если алгоритм вынужден до-запрашивать данные в несколько приемов при исполнении, данные могут измениться и стать не согласованными в контексте. Для этой проблемы сложно найти универсальное решение, но в каждой конкретной системе она как-то решается. Аналогичная проблема должна решаться при сохранении накопленных в контексте изменений.

[@Dansoid]

Что делать если моя логика не транслируется в SQL?

Использовать наш экстеншин, в котором и балки поддерживаются и рекурсивные CTE и оконные функции и кастомные агрегаты, update from, insert from. Мне ну очень редко приходилось писать сторед процедуры, все потому что библиотека заточена на написание многоэтажных сиквелов через Linq и никак не прячет от вас базу данных.

[@marshinov]

Запилили совместимость с ЕFCore?

[@Dansoid]

Это был интересный челенж. За неделю управился. Да, читаем метаданные из IModel, что знал об EF Core, то и поддержал.
В основном данные черпаю из их issues. Это печальное зрелище с детскими болезнями. Но, также, должен заметить пишут его складно и вдумчиво. За пару лет может и доведут до ума. Все сводится к дикой универсальности, да и чтоб in-memory для тестов работал и еще черти знает что, и пока от этого не отходят. Вот так универсальность и приводит к ограничениям и приоритетам фиксов проблем. Народ не унывает и клепает сторед процедуры, которые их же миграции превращают в фарс.

[@marshinov]

Строго говоря многие проблемы как по мне не на уровне библиотек, а в реализации LINQ. С Roslyn наверняка можно добавить специальный атрибутик для компиляции, чтобы гибче управлять тем, что за экспрешны в лямбды попадают, чтобы не в рантайме это фиксить, а компилировать сразу как надо. А совсем прекрасно было бы, если еще настроечка была, чтобы билд ломался, если лямбду не разобрать.

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

[@Dansoid]

Я с этим не согласен, все что они могут сделать в Roslyn это поддержать еще больше стейтментов в linq query (not i method chain). Плагин для рослина, разбирающий запрос, часто в принципе невозможен если части запроса разбросаны по функциям.
Все остальное разбирается на ура (ну не совсем ;))

Много сейчас проблем в основном с недоучетами в third party library Relinq. Ну, и мое субъективное мнение, в использовании ExpressionVisitor pattern, оно их тормозит просто неподетски.