Где-то в степиМСУ,
послушай, вот вопрос
EF схавает такую фишку
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
class Program
{
static void Main(string[] args)
{
var res= GetEnumerable(new {name = "", id = 1});
}
static IEnumerable<T> GetEnumerable<T>(T t)
{
return context.Database.SqlQuery<T>("SELECT name,id FROM dbo.Blogs");
}
}
конечно это имхо противоречит концепции, но может есть там такая французская булка?
зы сам не могу проверить ((
Сам по себе - не схавает, но для EF5 получилось допилить таким образом, чтобы динамический SQL можно было представить в виде типизированного IQueryable<T> с возможностью дальнейшего использования в других LINQ - запросах. Очень удобно для композиции запросов со временными таблицами.
Кода до фига, опишу ключевые моменты:
1. Пишется wrapper для SQL-провайдера (примеры есть в I-Net)
2. Динамический SQL инжектится в дерево выражений через вызов табличной функции. Функция в БД не нужна, она все равно заменится на последующих этапах. В момент инжекта функции сам динамический SQL и описание типа для IQueryable передается в функцию через строковые параметры в виде Expression.Constant.
3. Во wrappere провайдера перехватывается создание DbCommandDefinition и визитором проходится DbQueryCommandTree с заменой вызова фэйковой табличной функции на запрос (DbScanExpression) к динамически созданному EntitySet с definingquery, соответствующим нашему динамическому SQL. Текст динамического запроса и описание выходного типа достается из аргументов DbFunctionExpression в виде DbConstantExpression. Здесь вовсю дергаются internal и private из EF, код сгенерирован в виде dynamic-метода. Как показало изучение кода транслятора DbExpressionTree в SQL, EF не обращает внимания на то, что новый динамический тип физически не входит в наш MetadataWorkspace (хотя и приходится создавать в нем ссылку на наш EntityContainer).
4. Также в DbQueryCommandTree вносятся некоторые изменения в проекции DbNewInstanceExpression для преобразования выхлопа фэйковой функции к динамическому EntityType, сгенерированному на шаге 3.
Надеюсь, что при переходе на EF6 (Open-Source), игрищ с wrapper-ом и internal-методами можно будет избежать. Тогда можно будет попробовать оформить код более компактно, сейчас же, к сожалению, поделиться им не смогу, ибо он потянет за собой кучу кода из слоя доступа к данным.
