Why should you care?

ShopNest search uses SQL Server FULLTEXT or custom fn_ShippingEstimate — mapping functions keeps logic in SQL where it belongs.

See it live — copy this example

Paste into a .NET project with EF Core packages, then run with LocalDB/SQL Server (dotnet ef / dotnet run).

var term = "laptop";
var matches = await _context.Products
    .Where(p => EF.Functions.Like(p.Name, $"%{term}%"))
    .ToListAsync();

// Mapped UDF in DbContext:
[DbFunction("fn_ActiveDiscount", Schema = "dbo")]
public static decimal ActiveDiscount(int productId) => throw new NotSupportedException();

What happened?

• EF.Functions.Like translates to SQL LIKE with parameterization.
• DbFunction maps static method to dbo.fn_ActiveDiscount for use in LINQ.

Practice next

1. Use EF.Functions for provider builtins — Like, Collate, DateDiff.
2. Register UDF with HasDbFunction in OnModelCreating.
3. Ensure function exists in database before query runs.
4. Map dbo.fn_GetTaxRate with HasDbFunction and use in price Select.
5. Compare Like vs Contains case sensitivity on collation.

Remember

EF.Functions wraps SQL Server builtins. HasDbFunction maps UDFs into LINQ. Keeps computation server-side.

ShopNest search LIKE

Catalog search uses EF.Functions.Like for partial name match indexed with proper collation.

Outcome: Predictable SQL matching DBA full-text rollout plan.