Когда пишешь запрос строкой, то можно было составть эту строку динамически: select "" from ""..., где вместо кавычек можно было подставлять сущности и её параметры. В результате можно было написать один запрос-шаблон и вставлять в него нужные параметры. Как с этим обстоят дела в Entity Framework?

В данный момент я пишу так:

Выглядит хреново.

Знаю, что в Entity Framework можно тоже строку запросом послать через Database.SqlQuery, но тогда вся эта канва с ORM теряет смысл - нет готовой типизации результатов запроса, плюс контекст не отслеживает (как сказано в комментарии к этой функции) резальтаты таких запросов.

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

Алексей КЕсть Dynamic LINQ . Но это всё следствие неправильной структуры данных.
Хе-хе. У меня, оказывается, эта вкладка открыта в браузере уже года полтора-два, только затерялась. ))

Насчёт структуры данных. Ну а чего там можно придумать, чтобы можно было выбирать сущности и их атрибуты чисто запросом? EAV? Так его не везде применять можно и нужно. Да возьмём простой пример - две таблицы (как у меня в примере в первом посте) и только. Тут EAV не нужен, но селектор сущности и атрибутов охота.

AntonariyДля работы с базами она по-моему противопоказана. Похерена типизация с интеллисенсом
Эмм... Имена параметров и сущностей можно через рефлексию и выражения (Expression) вытащить. Но вот почему они сделали фразы в Where полностью строковыми, непонятно. Мне, например, уже достаточно, чтобы имена сущностей и их атрибутов чтобы можно было динамически задавать, а вот всякие проверки и действия уже лишнее.

Antonariyно сохранены, а может и приумножены минусы типа производительности. Лучше уж чистое ADO.
Так чистое ADO, вроде, ничего не типизирует, деревья выражений не создаёт. Поэтому и быстрее. За удобство заплатили скоростью (весь Дотнет на этом принципе построен).

Antonariyuser7320 Так чистое ADO, вроде, ничего не типизирует, деревья выражений не создаёт. Поэтому и быстрее. За удобство заплатили скоростью (весь Дотнет на этом принципе построен).Ты так говоришь, как будто открыл великую тайну.
Тогда я не понимаю недовольных возгласов о производительности кода от людей, которые понимают, что эти вещи были придуманы не для производительности кода. Причём возгласы вида (я не вас имею ввиду, а вообще иногда встречаются) "фу гавно нирикамедную этат фремворк! ни магли сделать фсё как в крузис или в джаве".

Алексей Кuser7320Насчёт структуры данных. Ну а чего там можно придумать, чтобы можно было выбирать сущности и их атрибуты чисто запросом?Традиционно, общие поля вынести в центральную таблицу. Завязать на неё таблицы со специфичными полями отношением один-к-одному. В центральную таблицу добавить поле "тип" или определять тип по наличию записи в "специфичной" таблице.

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

У меня так и есть - наследование и таблица с типами - см. вложение.

Затем, в коллеции (скажем, список-листбокс; и вообще, речь о WPF, если что) у меня намешаны книги и диски - суть, продукты. Не спрашивайте, зачем намешал, на самом деле ситуация сложнее, но допустим, что так. Кликаем на листбокс и выполняется команда, которая должна запросить данные по выбранному продукту. У команды только один параметр, и я передаю туда собственно выбранный предмет (SelectedItem). Я могу сделать и без команд, а, скажем, привязав свойство IsSelected модели представления к IsSelected листбокса. В любом случае, я получаю в код объект, который представляет собой либо книгу, либо диск (т. е. не просто продукт, а прямо потомковый тип известен).

Далее всё как в первом посте - тип продукта известен, сам экземпляр типа (или его айди) известен - могу сделать запрос. Но вот как теперь составить универсальный запрос в рамках строго типизированного ORM при такой схеме БД, чтобы и к книгам (или машинам), и к дискам (или столам) можно было обращаться в БД? Или менять схему БД?