Introduction

Entity Framework does not have a C# language operator named LIKE because LIKE is a SQL concept, not a LINQ keyword. In practice, you either express simple pattern matching with string methods such as Contains, StartsWith, and EndsWith, or you use the framework's provider-aware Like function when you want SQL-style wildcard control.

Use LINQ String Methods for Common Cases

For many queries, normal string methods are the cleanest answer. Entity Framework translates them into database-side pattern matching when the provider supports it.

1using System.Linq;
2
3var containsOrange = context.Products
4    .Where(p => p.Name.Contains("Orange"))
5    .ToList();
6
7var startsWithPro = context.Products
8    .Where(p => p.Name.StartsWith("Pro"))
9    .ToList();
10
11var endsWithXL = context.Products
12    .Where(p => p.Name.EndsWith("XL"))
13    .ToList();

Conceptually, those map to familiar SQL patterns:

• 'Contains("Orange") behaves like %Orange%'
• 'StartsWith("Pro") behaves like Pro%'
• 'EndsWith("XL") behaves like %XL'

This is often enough, and it keeps the query readable as ordinary LINQ.

Use EF.Functions.Like When You Need Wildcards

If you want direct control over the SQL pattern, use EF.Functions.Like in Entity Framework Core.

1using Microsoft.EntityFrameworkCore;
2
3var matches = context.Products
4    .Where(p => EF.Functions.Like(p.Name, "%Orange%"))
5    .ToList();

This is clearer when you already know the exact wildcard pattern you want to send to the database.

Examples:

• '%abc% means the text appears anywhere'
• 'abc% means the value starts with abc'
• '%abc means the value ends with abc'
• '_ matches a single character'

var codeMatches = context.Products
    .Where(p => EF.Functions.Like(p.Code, "A_1%"))
    .ToList();

That query matches values beginning with A, followed by any single character, then 1, and then any remaining suffix.

Version Context Matters

The exact helper depends on which EF family you are using.

• EF Core gives you EF.Functions.Like
• classic Entity Framework often relies more on translated string methods or provider-specific support
• Entity SQL also has its own LIKE syntax, but that is not the same as LINQ-to-Entities usage

So before copying an example, check whether it targets classic EF, EF Core, or a specific provider. The high-level idea is stable, but the exact API shape differs.

Do Not Drop to Raw SQL Too Early

Many developers assume they need raw SQL as soon as pattern matching gets involved. Usually they do not. A normal EF query stays composable, typed, and easier to maintain.

1using Microsoft.EntityFrameworkCore;
2
3var query = context.Products
4    .Where(p => EF.Functions.Like(p.Name, "%Orange%"))
5    .OrderBy(p => p.Name)
6    .Select(p => new
7    {
8        p.Id,
9        p.Name
10    });
11
12var results = query.ToList();

The moment you switch to raw SQL for a simple wildcard match, you give up some composability and often gain very little.

Raw SQL is still available when the query truly needs vendor-specific behavior, but it should not be the default answer for ordinary LIKE matching.

Performance Depends on the Pattern

Not all LIKE searches cost the same. Pattern shape matters a lot:

• prefix searches such as abc% are often friendlier to indexes
• suffix searches such as %abc are harder
• contains searches such as %abc% are usually the most flexible and often the most expensive

That means the query may be semantically correct and still perform poorly because of the wildcard placement. If performance matters, start by checking whether the business requirement really needs a leading wildcard.

Collation and Provider Behavior Affect the Result

Case sensitivity is usually governed by the database collation, not by Entity Framework alone. The same LINQ query can behave differently on two databases if their collation rules differ.

Provider differences matter too. The translation behavior for SQL Server, PostgreSQL, and SQLite is not identical in every detail. That is another reason to think in terms of "translated to the provider" instead of imagining one universal SQL result.

If a query behaves unexpectedly, inspect the generated SQL and the database collation before assuming the ORM is wrong.

Common Pitfalls

One common mistake is assuming LIKE always requires raw SQL. Often, normal LINQ string methods or EF.Functions.Like are enough.

Another pitfall is using %text% everywhere without considering the cost of leading wildcards.

A third issue is copying examples across EF versions without checking whether they target EF Core or classic EF.

Finally, do not call ToList() too early. If you materialize the query first and then filter in memory, the database translation is lost and the whole point of using EF for query translation disappears.

Summary

• In Entity Framework, SQL LIKE behavior is usually expressed with LINQ string methods or EF.Functions.Like.
• Use Contains, StartsWith, and EndsWith for common readable cases.
• Use EF.Functions.Like in EF Core when you need explicit wildcard control.
• Pattern shape affects performance, especially when the wildcard appears at the start.
• Always interpret the result in the context of the EF version, database provider, and database collation.