Мое субьективоное/основанное на опыте мнение об этих «фичах»:
Lazy load — на серверах, как правило, скорее вредно, так как увеличивает количество запросов иногда неоправданно сильно. Если используется lazy load, я ищу причину такой необходимости. И опять же, как правило, это просто непродуманный дизайн. Cache — вещь нужная, много где оправданная, но если бездумно ее включать, то неприятностей не оберешься. Ревалидация кеша это задача не хуже чем само создание солюшина. Перекладывать это бесконтрольно на ORM равносильно самоубийству.
Утверждение «не вытягивать дублирующиеся сущности» очень далеко от реальности. Они вытягиваются! Просто отсекаются при материализации. Если вы думаете что здесь получили существенный профит — вас обманули.
Я видел что такие финты EF Core проделывает с группировкой. Записи вполне могут прогруппироваться на клиенте. Я бы очень внимательно следил за SQL которые в конце концов генерятся.
Вы путаете change tracking с самим понятием ORM. Легковесные ORM это делают из коробки. Им совсем не обязательно тянуть запись с сервера чтобы ее изменить или удалить. Из-за таких мелких выборок серьезно проседает SQL сервер в высоконагруженых системах.
Да, конечно, вижу изврат на ровнм месте. Действительно уже кучу раз могли придумать поддержку кастомных функций, об кастомных агрегатах и оконных функциях я вообще молчу.
Ну что же, я рад чо у нас в linq2db это занимает ровно один чих: github.com/linq2db/linq2db/blob/master/Source/LinqToDB/Sql/Sql.cs#L468
Так расширяйте это комюнити, а не двигайтесть за толпой ;)
Я как один из разработчиков linq2db, скажу что у вас не проблема, а проблемка.
Ассоциации любой сложности, ремаппинг полей на лету и гибкая раширяемость.
Огромное количество юнит тестов гарантируют что все это будет работать и через 10 лет.
А по скорости… перед нами только ручной маппер.
Вам надо было попробовать linq2db
Там и не такое можно сгенерировать. Практически любой полет фантазии реализуем. EF Core, скорее всего не выпустит вас за свои рамки, а они очеь строгие.
Почему же так категорично не попробовав. Скорее всего такое мнение складывается после неудачной попытки использования EF. Как результат все бегут к Dapper, теряя все преимущества типизации.
Я такие трехэтажные linq запросы писал что дух захватывало. Все это превращалось в соптимизированный SQL.
Именно для этого есть linq2db. Query decomposition там работает на ура с многочисленными плюшками оптимизации. Для меня лучше написать linq запрос который компилятором проверится и я буду спокоен, что ничего из-за изменения модели не поломал.
Lazy load — на серверах, как правило, скорее вредно, так как увеличивает количество запросов иногда неоправданно сильно. Если используется lazy load, я ищу причину такой необходимости. И опять же, как правило, это просто непродуманный дизайн.
Cache — вещь нужная, много где оправданная, но если бездумно ее включать, то неприятностей не оберешься. Ревалидация кеша это задача не хуже чем само создание солюшина. Перекладывать это бесконтрольно на ORM равносильно самоубийству.
Утверждение «не вытягивать дублирующиеся сущности» очень далеко от реальности. Они вытягиваются! Просто отсекаются при материализации. Если вы думаете что здесь получили существенный профит — вас обманули.
То что здесь описано лишь одна сотая часть того что может LinqToDB. Уже и не припомню когда голые SQL писал.
github.com/linq2db/linq2db/blob/master/Source/LinqToDB/Sql/Sql.cs#L103
Ну что же, я рад чо у нас в linq2db это занимает ровно один чих:
github.com/linq2db/linq2db/blob/master/Source/LinqToDB/Sql/Sql.cs#L468
Но похоже часто нужны шашечки вместо того чтобы ехать.
Я как один из разработчиков linq2db, скажу что у вас не проблема, а проблемка.
Ассоциации любой сложности, ремаппинг полей на лету и гибкая раширяемость.
Огромное количество юнит тестов гарантируют что все это будет работать и через 10 лет.
А по скорости… перед нами только ручной маппер.
Там и не такое можно сгенерировать. Практически любой полет фантазии реализуем. EF Core, скорее всего не выпустит вас за свои рамки, а они очеь строгие.
Я такие трехэтажные linq запросы писал что дух захватывало. Все это превращалось в соптимизированный SQL.