🤔💭 TLDR; By using QueryableValues, you can incorporate in-memory collections into your EF queries with outstanding performance and flexibility.

This library allows you to efficiently compose an IEnumerable<T> in your Entity Framework Core queries when using the SQL Server Database Provider. You can accomplish this by using the AsQueryableValues extension method that's available on the DbContext class. The query is processed in a single round trip to the server, in a way that preserves its execution plan, even when the values within the IEnumerable<T> are changed on subsequent executions.

Highlights

• ✨ Enables the composition of in-memory data within your queries, utilizing both simple and complex types.
• 👌 Works with all versions of SQL Server supported by Entity Framework Core.
• ⚡ Automatically uses the most efficient strategy compatible with your SQL Server instance and configuration.
• ✅ Boasts over 140 tests for reliability and compatibility, giving you added confidence.

For a detailed explanation of the problem solved by QueryableValues, please continue reading here.

💡 Still on Entity Framework 6 (non-core)? Then QueryableValues EF6 Edition is what you need.

If you feel that this solution has provided you some value, please consider buying me a ☕.

Your ⭐ on this repository also helps! Thanks! 🖖🙂

QueryableValues is distributed as a NuGet Package. The major version number of this library is aligned with the version of Entity Framework Core by which it's supported (e.g. If you are using EF Core 5, then you must use version 5 of QueryableValues).

Look for the place in your code where you are setting up your DbContext and calling the UseSqlServer extension method, then use a lambda expression to access the SqlServerDbContextOptionsBuilder provided by it. It is on this builder that you must call the UseQueryableValues extension method as shown in the following simplified examples:

When using the OnConfiguring method inside your DbContext:

using BlazarTech.QueryableValues;

public class MyDbContext : DbContext
{
    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        optionsBuilder.UseSqlServer(
            "MyConnectionString",
            sqlServerOptionsBuilder =>
            {
                sqlServerOptionsBuilder.UseQueryableValues();
            }
        );
    }
}

When setting up the DbContext at registration time using dependency injection:

using BlazarTech.QueryableValues;

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddDbContext<MyDbContext>(optionsBuilder => {
            optionsBuilder.UseSqlServer(
                "MyConnectionString",
                sqlServerOptionsBuilder =>
                {
                    sqlServerOptionsBuilder.UseQueryableValues();
                }
            );
        });
    }
}

💡 UseQueryableValues offers an optional options delegate for additional configurations.

The AsQueryableValues extension method is provided by the BlazarTech.QueryableValues namespace; therefore, you must add the following using directive to your source code file for it to appear as a method of your DbContext instance:

using BlazarTech.QueryableValues;

💡 If you access your DbContext via an interface, you can also make the AsQueryableValues extension methods available on it by inheriting from the IQueryableValuesEnabledDbContext interface.

Below are a few examples composing a query using the values provided by an IEnumerable<T>.

💡 Supports Byte, Int16, Int32, Int64, Decimal, Single, Double, DateTime, DateTimeOffset, DateOnly, TimeOnly, Guid, Char, String, and Enum.

Using the Contains LINQ method:

// Sample values.
IEnumerable<int> values = Enumerable.Range(1, 10);

// Example #1 (LINQ method syntax)
var myQuery1 = dbContext.MyEntities
    .Where(i => dbContext
        .AsQueryableValues(values)
        .Contains(i.MyEntityID)
    )
    .Select(i => new
    {
        i.MyEntityID,
        i.PropA
    });

// Example #2 (LINQ query syntax)
var myQuery2 = 
    from i in dbContext.MyEntities
    where dbContext
        .AsQueryableValues(values)
        .Contains(i.MyEntityID)
    select new
    {
        i.MyEntityID,
        i.PropA
    };

Using the Join LINQ method:

// Sample values.
IEnumerable<int> values = Enumerable.Range(1, 10);

// Example #1 (LINQ method syntax)
var myQuery1 = dbContext.MyEntities
    .Join(
        dbContext.AsQueryableValues(values),
        i => i.MyEntityID,
        v => v,
        (i, v) => new
        {
            i.MyEntityID,
            i.PropA
        }
    );

// Example #2 (LINQ query syntax)
var myQuery2 = 
    from i in dbContext.MyEntities
    join v in dbContext.AsQueryableValues(values) on i.MyEntityID equals v 
    select new
    {
        i.MyEntityID,
        i.PropA
    };

💡 Must be an anonymous or user-defined type with one or more simple type properties, including Boolean.

// Performance Tip:
// If your IEnumerable<T> item type (T) has many properties, project only 
// the ones you need to a new variable and use it in your query.
var projectedItems = items.Select(i => new { i.CategoryId, i.ColorName });

// Example #1 (LINQ method syntax)
var myQuery1 = dbContext.Product
    .Join(
        dbContext.AsQueryableValues(projectedItems),
        p => new { p.CategoryId, p.ColorName },
        pi => new { pi.CategoryId, pi.ColorName },
        (p, pi) => new
        {
            p.ProductId,
            p.Description
        }
    );

// Example #2 (LINQ query syntax)
var myQuery2 = 
    from p in dbContext.Product
    join pi in dbContext.AsQueryableValues(projectedItems) on new { p.CategoryId, p.ColorName } equals new { pi.CategoryId, pi.ColorName }
    select new
    {
        p.ProductId,
        p.Description
    };

About Complex Types

⚠️ All the data provided by this type is transmitted to the server; therefore, ensure that it only contains the properties you need for your query. Not following this recommendation will degrade the query's performance.

⚠️ There is a limit of up to 10 properties for any given simple type (e.g. cannot have more than 10 Int32 properties). Exceeding that limit will cause an exception and may also suggest that you should rethink your strategy.

The following benchmarks consist of simple EF Core queries that have a dependency on a random sequence of Int32, Guid, and String values via the Contains LINQ method. It shows the performance differences between not using and using QueryableValues. In practice, the benefits of using QueryableValues are more dramatic on complex EF Core queries and busy environments.

BenchmarkDotNet v0.13.10, Windows 11 (10.0.22621.2715/22H2/2022Update/SunValley2)
AMD Ryzen 9 6900HS Creator Edition, 1 CPU, 16 logical and 8 physical cores
.NET SDK 8.0.100
  [Host]     : .NET 8.0.0 (8.0.23.53103), X64 RyuJIT AVX2
  Job-EBAAJF : .NET 8.0.0 (8.0.23.53103), X64 RyuJIT AVX2

Server=True  InvocationCount=200  IterationCount=25
RunStrategy=Monitoring  UnrollFactor=1  WarmupCount=1

Microsoft SQL Server 2022 (RTM) - 16.0.1000.6 (X64) 
Oct  8 2022 05:58:25 
Copyright (C) 2022 Microsoft Corporation
Express Edition (64-bit) on Windows 10 Pro 10.0 <X64> (Build 22621: ) (Hypervisor)

• The SQL Server instance was running in the same system where the benchmarks were executed.
• Shared Memory is the only network protocol that's enabled on this instance.

Legend:

• Without: Plain EF.
• With (XML): EF with QueryableValues using the XML serializer.
• With (JSON): EF with QueryableValues using the JSON serializer.

• 7.2.0

When Entity Framework Core is set up to use the SQL Server Database Provider and it detects the use of variables in a query, in most cases it provides its values as parameters to an internal SqlCommand object that will execute the translated SQL statement. This is done efficiently by using the sp_executesql stored procedure behind the scenes, so if the same SQL statement is executed a second time, the SQL Server instance will likely have a computed execution plan in its cache, thereby saving time and system resources.

We have been in the situation where we need to build a query that must return one or more items based on a sequence of values. The common pattern to do this makes use of the Contains LINQ extension method on the IEnumerable<T> interface, then we pass the property of the entity that must match any of the values in the sequence. This way we can retrieve multiple items with a single round trip to the database as shown in the following example:

var myQuery = dbContext.MyEntities
    .Where(i => listOfValues.Contains(i.MyEntityID))
    .Select(i => new
    {
        i.MyEntityID,
        i.PropB,
        i.PropC
    });

The previous query will yield the expected results, but there's a catch. If the sequence of values in our list is different on every execution, the underlying SQL query will be built in a way that's not optimal for SQL Server's query engine. Wasting system resources like CPU, memory, IO, and potentially affecting other queries in the instance.

Let's take a look at the following query and the SQL that is generated by the SQL Server Database Provider as of version 5.0.11 when the query is materialized:

var listOfValues = new List<int> { 1, 2, 3 };
var anotherVariable = 100;
var myQuery = dbContext.MyEntities
    .Where(i =>
        listOfValues.Contains(i.MyEntityID) ||
        i.PropB == anotherVariable
    )
    .Select(i => new
    {
        i.MyEntityID,
        i.PropA
    })
    .ToList();

Generated SQL

exec sp_executesql N'SELECT [m].[MyEntityID], [m].[PropA]
FROM [dbo].[MyEntity] AS [m]
WHERE [m].[MyEntityID] IN (1, 2, 3) OR ([m].[PropB] = @__p_1)',N'@__p_1 bigint',@__p_1=100

Here we can observe that the values in our list are being hardcoded as part of the SQL statement provided to sp_executesql as opposed to them being injected via a parameter, as is the case for our other variable holding the value 100.

Now, let's add another item to the list of values and execute the query again:

exec sp_executesql N'SELECT [m].[MyEntityID], [m].[PropA]
FROM [dbo].[MyEntity] AS [m]
WHERE [m].[MyEntityID] IN (1, 2, 3, 4) OR ([m].[PropB] = @__p_1)',N'@__p_1 bigint',@__p_1=100

As we can see, a new SQL statement was generated just because we modified the list that's being used in our Where predicate. This has the detrimental effect that a previously cached execution plan cannot be reused, forcing SQL Server's query engine to compute a new execution plan every time it is provided with a SQL statement that it hasn't seen before and increasing the likelihood of flushing other plans in the process.

💡 To address this issue, EF8 now incorporates the use of the OPENJSON function when possible. The change was tracked by this EF Core issue. As of EF version 8.0.0, QueryableValues remains superior in terms of compatibility and performance.

This library provides you with the AsQueryableValues extension method made available on the DbContext class. It solves the problem explained above by allowing you to build a query that will generate a SQL statement for sp_executesql that will remain constant execution after execution, allowing SQL Server to do its best every time by using a previously cached execution plan. This will speed up your query on subsequent executions, and conserve system resources.

Let's take a look at the following query making use of this method, which is functionally equivalent to the previous example:

var myQuery = dbContext.MyEntities
    .Where(i =>
        dbContext.AsQueryableValues(listOfValues).Contains(i.MyEntityID) ||
        i.PropB == anotherVariable
    )
    .Select(i => new
    {
        i.MyEntityID,
        i.PropA
    });

Generated SQL

declare @p3 xml
set @p3=convert(xml,N'<R><V>1</V><V>2</V><V>3</V></R>')
exec sp_executesql N'SELECT [m].[MyEntityID], [m].[PropA]
FROM [dbo].[MyEntity] AS [m]
WHERE EXISTS (
    SELECT 1
    FROM (
        SELECT I.value(''. cast as xs:integer?'', ''int'') AS [V] FROM @p0.nodes(''/R/V'') N(I)
    ) AS [q]
    WHERE [q].[V] = [m].[MyEntityID]) OR ([m].[PropB] = @__p_1)',N'@p0 xml,@__p_1 bigint',@p0=@p3,@__p_1=100

Now, let's add another item to the list of values and execute the query again:

declare @p3 xml
set @p3=convert(xml,N'<R><V>1</V><V>2</V><V>3</V><V>4</V></R>')
exec sp_executesql N'SELECT [m].[MyEntityID], [m].[PropA]
FROM [dbo].[MyEntity] AS [m]
WHERE EXISTS (
    SELECT 1
    FROM (
        SELECT I.value(''. cast as xs:integer?'', ''int'') AS [V] FROM @p0.nodes(''/R/V'') N(I)
    ) AS [q]
    WHERE [q].[V] = [m].[MyEntityID]) OR ([m].[PropB] = @__p_1)',N'@p0 xml,@__p_1 bigint',@p0=@p3,@__p_1=100

Great! The SQL statement provided to sp_executesql remains constant. In this case SQL Server can reuse the execution plan from the previous execution.

You don't have to take my word for it! Let's see a trace of what's going on under the hood when both of these queries are executed multiple times, adding a new value to the list after each execution. First, five executions of the one making direct use of the Contains LINQ method (orange), and then five executions of the second one making use of the AsQueryableValues extension method on the DbContext (green):

^{Queries executed against SQL Server 2017 Express (14.0.2037) running on a resource constrained laptop.}

As expected, none of the queries in the orange section hit the cache. On the other hand, after the first query in the green section, all the subsequent ones hit the cache and consumed fewer resources.

Now, focus your attention to the first query of the green section. Here you can observe that there's a cost associated with this technique, but this cost can be offset in the long run, especially when your queries are not trivial like the ones in these examples.

🎉 QueryableValues now supports JSON serialization, which improves its performance compared to using XML. By default, QueryableValues will attempt to use JSON if it is supported by your SQL Server instance and database configuration.

QueryableValues makes use of the XML parsing capabilities in SQL Server, which are available in all the supported versions of SQL Server to date. The provided sequence of values are serialized as XML and embedded in the underlying SQL query using a native XML parameter, then it uses SQL Server's XML type methods to project the query in a way that can be mapped by Entity Framework Core.

This is a technique that I have not seen being used by other popular libraries that aim to solve this problem. It is superior from a latency standpoint because it resolves the query with a single round trip to the database and most importantly, it preserves the query's execution plan even when the content of the XML is changed.

PRs are welcome! 🙂