В LINQ to SQL, как вы передаете части запроса LINQ в функцию

StackOverflow https://stackoverflow.com/questions/434480

Вопрос

Можно ли передать части запроса linq в функцию? Я хочу создать общий интерфейс для моего DAL, который всегда использует один и тот же интерфейс запросов. Например, 

List<T> Get(Join j, Where w, Select s){    
    return currentDataContext<T>.Join(j).Where(w).Select(s).ToList();    
}

Это возможно? Я думаю, что это будет сделано с деревьями выражений, но я не смог найти примеры этого.

Это было полезно?

Решение

Ну, " join " это сложно, потому что очень трудно выразить соединение - но такие вещи, как, где / select / orderby, довольно просты ...

Действительно, это всего лишь случай объединения различных методов LINQ в IQueryable<T>, которые обычно принимают Expression<Func<...>> для некоторой комбинации. Таким образом, базовый выбор с необязательным предикатом будет: 

    public IQueryable<T> Get<T>(
        Expression<Func<T,bool>> predicate
        ) where T : class
    {
        IQueryable<T> query = (IQueryable<T>)GetTable(typeof(T));
        if (predicate != null) query = query.Where(predicate);
        return query;
    }

Я бы тоже хотел вернуться ToList(), так как он полностью компонуется. Если абоненту нужен список, он всегда может использовать <=> в нем ... или (например): 

    using(var ctx = new MyDataContext(CONN))
    {
        ctx.Log = Console.Out;
        int frCount = ctx.Get<Customer>(c => c.Country == "France").Count();
    }

который (используя Northwind) выполняет запрос: 

SELECT COUNT(*) AS [value]
FROM [dbo].[Customers] AS [t0]
WHERE [t0].[Country] = @p0

Проблема с включением " select " (проекция) в запросе заключается в том, что вы получите несколько общих типов. Поскольку вы часто хотите, чтобы проекция была анонимным типом, было бы практически невозможно указать тип проекции (анонимный) и табличного типа, и он не будет вызываться.

На самом деле, мне интересно, есть ли польза от написания такого метода вообще. Я мог бы просто придерживаться базового метода: 

    public IQueryable<T> Get<T>() where T : class
    {
        return (IQueryable<T>)GetTable(typeof(T));
    }

И позвольте вызывающему составить его по своему усмотрению - возможно, с синтаксисом запроса: 

       var list = (from cust in ctx.Get<Customer>()
                   where cust.Country == "France"
                   select cust.CompanyName).Take(10).ToList();

Который использует: 

SELECT TOP (10) [t0].[CompanyName]
FROM [dbo].[Customers] AS [t0]
WHERE [t0].[Country] = @p0
<Ч>

В качестве альтернативы, если вы действительно хотите включить порядок и проекцию, то метод расширения является наиболее практичным подходом; тогда вам не нужно указывать оригинал (источник) T (что делает его не вызываемым при смешении с anon-типами): 

public static class QueryExtension
{
    public static IQueryable<TProjection>
        Get<TSource, TProjection, TOrderKey>(
            this IQueryable<TSource> source,
            Expression<Func<TSource, bool>> where, // optional
            Expression<Func<TSource, TProjection>> select,
            Expression<Func<TProjection, TOrderKey>> orderBy)
    {
        if (where != null) source = source.Where(where);
        return source.Select(select).OrderBy(orderBy);
    }
}

Затем рассмотрим метод DAL, например: 

    public List<string> Countries()
    {
        return Customers.Get(
            x=>x.CompanyName != "",
            x=>x.Country,
            x=>x).Distinct().ToList();
    }

Который использует (опять же, с Northwind): 

SELECT DISTINCT [t0].[Country]
FROM [dbo].[Customers] AS [t0]
WHERE [t0].[CompanyName] <> @p0

Другие советы

Проверьте этот универсальный класс:

Вы можете использовать библиотеку динамических выражений, доступную в примерах Linq, с этой библиотекой расширений вы можете передавать предложения linq для где и т. д.

Скачать можно отсюда образцы linq

Вы можете использовать Dynamic LINQ и передать параметры в виде строк.

Marc Gravell & # 9830; как обычно, дал очень проницательный ответ, но я действительно думаю, что методы, которые принимают IQueryables и добавляют ограничения, будут работать в большинстве случаев, и они сохраняют код более понятный и легко обслуживаемый. Например: 

//Join
public static IQueryable<IContract> AllContracts(this IQueryable<IAccount> accounts, ISession s ) {
          return from a in accounts
                 from contract in s.Query<IContract()
                 where (a.Id == contract.AccountId)
                 select contract;
    }
//Where
public static IQueryable<IContract> Active(this IQueryable<IContract> contracts) {
          return from contract in contracts
                 where (contract.Active == true)
                 select contract;
    }

Затем вы можете смешивать и сопоставлять их следующим образом: 

IQueryable<IContract> activeContracts = s.Query<IAccount>()
            .Where(o => o.Name == "XXX")
            .GetContracts(s)
            .Active();

Я использую методы расширения и LINQ от NHiberante, предоставляющий здесь метод Query , но его можно легко переписать без статических методов и с любым поставщиком LINQ.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top