Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Gattaka, Вы писали:

G>>Здравствуйте, gandjustas, Вы писали:

G>>>>И давайте от противного. А может ли ваш linq добавить этот option (recompile)? Нет не может — будет кучу запросов генерить
G>>>Правильно. Генерить кучу запросов выгоднее. Хотя наверное linq2db может, я не проверял.
G>>Выгоднее это да, но насколько? План запроса компилируется пару милисекунд, можно для каждого конкретного посмотреть в плане. И на чем мы экономим? Если сам запрос выполняется пару секунд. Ну... если хорошо скомпилировался. Если плохо — полчаса. Здесь баланс нужно соблюдать. На самом деле что ORM хорошо делает, это простейший CRUD, самый простейший. И сценарий что вы описали. Но это по факту Read.
G>Баланс чего? Тут нет tradeoff, запросы, сгенерированные Linq не требуют перекомпиляции, а рукопашные требуют.

G>>Ну и что это за уровень абстракции в таком случае? Это всего лишь способ писать SQL на C#. Извращение...
G>Ну и пусть извращение, какая разница? Я готов заниматься любыми извращениями если сокращает затраты.


Вобще то это подмена понятий. Приложение ведь не состоит из одних фильтраций, это даже не 0,0001% от всего разнообразия запросов. А вот как раз с ними и возникают проблемы.
Я уже описывал что за проблемы — при работе с дискриминаторами в 2 раза больше джойнов вместо условий в самих джойнах. И что тогда будет толку от кучи конкретных запросов, которые не перекомпилируются, но содержат лишние джойны?
Если посмотреть на EF там постоянно запросы вида select ... from (select ... запрос...) — почему-то селект из селекта, очень странно.
Вспомнилось про NH недавнее чудо — при обновлении объекта происходит не обновление конкретного поля, а перезапись всех полей строчки. (Как у EF сейчас с этим?). Это можно разрулить с помощью аттрибута на свойстве сущности, но опять же надо везде ставить, что несколько портит внешний вид самой сущности.