Forem: El Mehdi Taii

🚀 Simplify Your C# Collections with the Spread Operator (..)

El Mehdi Taii — Sat, 13 Dec 2025 20:08:57 +0000

If you're still using Array.Copy(), .Concat(), or .AddRange() to combine collections in C#, you're working too hard. C# 13 introduced the spread operator (..) that makes collection manipulation cleaner, faster, and more intuitive.

The Problem

Traditional collection operations in C# are verbose and require multiple steps. Whether you're combining arrays, adding elements, or copying collections, you end up with code that's harder to read and maintain.

The Solution: Spread Operator (..)

The spread operator (..) lets you expand collections inline, making your code more expressive and eliminating boilerplate. Think of it as "unpacking" a collection right where you need it.
Code Examples

1️⃣** Basic Collection Combining**

2️⃣ Adding Elements to Collections

3️⃣ Working with Different Collection Types

4️⃣ Real-World Use Case: Building Configuration

5️⃣ Creating Copies

6️⃣ API Response Building

Key Benefits
✅ Readability: Code intention is crystal clear
✅ Less Boilerplate: No more manual array copying or .Concat() chains
✅ Type Safe: Full compile-time type checking
✅ Performance: Efficient memory allocation
✅ Flexibility: Works with any IEnumerable

Performance Comparison

Best Practices
🔹 Use spread operator for:

Combining multiple collections
Creating collection copies
Building collections with mixed sources
Dynamic collection composition

🔹 Remember:

Creates shallow copies (like most collection operations)
Works with any IEnumerable type
Can be mixed with individual elements
Multiple spreads in one expression are fine

🔹 Common Patterns:

Requirements
⚠️ Note: The spread operator requires:

C# 13 or later
.NET 9 or later

If you're on older versions, stick with traditional methods like .Concat(), .AddRange(), or Array.Copy().
When NOT to Use Spread Operator
🔹 If you need to modify elements during combination (use LINQ .Select() instead)
🔹 If you're working with very large collections and need specific performance optimizations
🔹 If you're on C# 12 or earlier (not available)
The Bottom Line
The spread operator is a small syntax addition that makes a huge difference in code clarity. If you're building, combining, or copying collections, stop writing boilerplate and start using ... Your future self (and your code reviewers) will thank you.

🚀 Boost Your EF Core Performance with AsNoTracking()

El Mehdi Taii — Fri, 12 Dec 2025 10:10:50 +0000

If you're working with Entity Framework Core and wondering why your read-heavy operations feel sluggish, you might be paying a hidden performance cost: change tracking overhead.

The Problem

By default, EF Core tracks every entity it retrieves from the database. This tracking mechanism monitors changes to entities so that when you call SaveChanges(), EF Core knows exactly what to update. While powerful for CRUD operations, this comes with memory and CPU overhead—especially problematic when you're just reading data.

The Solution: AsNoTracking()

The AsNoTracking() method tells EF Core: "I'm only reading this data, don't track changes." This eliminates tracking overhead and can significantly improve performance for read-only scenarios.

Code Examples

1️⃣ Basic Query with AsNoTracking()

2️⃣ Comparing Tracking vs No-Tracking Behavior

3️⃣ Performance Use-Case: API Endpoints & Dashboards

4️⃣ When NOT to Use AsNoTracking()

5️⃣ AsNoTrackingWithIdentityResolution()

Key Benefits
✅ Performance: 10-30% faster queries in read-heavy scenarios
✅ Memory: Reduced memory footprint—no tracking metadata stored
✅ Scalability: Better throughput for high-volume read operations
✅ Simplicity: One method call for immediate gains

Best Practices
🔹 Use AsNoTracking() for:

Read-only API endpoints
Reports and dashboards
Data export operations
Search and filtering queries

🔹 Avoid AsNoTracking() when:

You need to update entities afterward
Working with complex object graphs where identity matters
The performance gain is negligible (very small result sets)

🔹 Global Configuration:

🔹 Use AsNoTrackingWithIdentityResolution() when you need proper entity identity without tracking overhead (EF Core 5.0+)

The Bottom Line

If you're querying data without modifying it, you're probably paying for tracking you don't need. Add .AsNoTracking() to your read queries and watch your application's performance improve.

🚀 Entity Framework Core 10: The JSON & Complex Types Revolution Is Here!

El Mehdi Taii — Wed, 03 Dec 2025 10:36:47 +0000

EF Core 10 transforms how we model data with two major innovations that radically simplify development.

Complex Types: No More Unnecessary Tables

Complex types let you model contained types within your entities without their own identity, avoiding traditional JOINs and delivering better performance. No need to create separate tables for every structured object!

JSON Columns: Flexibility Without Compromise

You can now map complex properties to single JSON columns, perfect for dynamic or semi-structured data:

Native JSON Type in SQL Server 2025: Performance & Security

The new JSON data type brings significant efficiency improvements and a safer way to store and interact with JSON. On Azure SQL Database and SQL Server 2025, EF automatically uses the native JSON type by default.

Concrete Benefits:

Type-safe queries on your JSON documents
Bulk updates with ExecuteUpdateAsync directly in JSON
No more schema migrations to add fields
Native JSON indexing for optimal performance
Cleaner, more maintainable code

EF Core 10 represents a major leap forward in handling structured and semi-structured data. Now's the time to explore these new capabilities!

🚀 Introducing Better API Documentation with ProducesResponseType

El Mehdi Taii — Tue, 02 Dec 2025 09:16:16 +0000

Introducing ProducesResponseType

We've all been there: consuming an API endpoint and having no clue what response to expect, digging through code to figure out status codes, or maintaining Swagger docs that never match the actual implementation. It's frustrating, time-consuming, and leads to runtime errors that could've been caught earlier. That's why I'm excited to highlight ProducesResponseType—a powerful attribute in .NET Core that explicitly declares your API response contracts, making your endpoints self-documenting and giving both developers and tools like Swagger complete clarity on what your API returns.

The Problem

Ever worked with an API and had no idea what response types to expect? Or spent hours debugging because the documentation didn't match the actual responses?
If you're building APIs in .NET Core, you know the struggle: clients consume your endpoints blindly, Swagger docs are incomplete, and developers waste time guessing response structures.

The Solution

The ProducesResponseType attribute is a game-changer for .NET Core API development. It explicitly declares what your endpoints return, making your APIs self-documenting and predictable.
This attribute tells both developers AND tools (like Swagger/OpenAPI) exactly what to expect from your endpoints—including status codes and response types.

Code Examples

Example 1: Basic Usage

Example 2: Multiple Success Responses

Example 3: Generic Response with Pagination

Example 4: File Download Endpoint

Key Benefits

✅ Crystal-Clear Documentation – Swagger/OpenAPI automatically generates accurate, comprehensive API docs
✅ Better Developer Experience – Frontend teams know exactly what to expect without trial and error
✅ Type Safety – Strong typing means fewer runtime errors and easier client code generation
✅ Improved Maintainability – Response contracts are explicit, making refactoring safer
✅ Enhanced Tooling – IDEs and API clients can provide better IntelliSense and validation
✅ Professional Standards – Your API follows industry best practices for REST documentation

The Bottom Line
ProducesResponseType transforms your .NET Core APIs from black boxes into well-documented, predictable contracts. It's a small attribute that makes a massive difference in API quality and team productivity.

🚀 How to Build Dynamic LINQ Queries Easily with WhereDynamic in .NET8+

El Mehdi Taii — Tue, 02 Dec 2025 08:30:02 +0000

Introducing WhereDynamic

We've all been there: writing endless if statements to build conditional queries, or duplicating logic across multiple endpoints just to handle different filter combinations. It's messy, error-prone, and hard to maintain.
That's why I'm excited to announce WhereDynamic a powerful new feature that lets you build LINQ queries dynamically at runtime, without hardcoding filters or sacrificing type safety.

The Problem

When building APIs or data-driven applications with .NET and Entity Framework, we often need to apply filters based on user input. Traditional approaches lead to bloated code:

This doesn't scale well and becomes a maintenance nightmare.

The Solution
WhereDynamic allows you to construct flexible, runtime queries with a clean, fluent API:

Practical Use Cases

1 - Advanced Search Filters

2 - Multi-Tenant Data Filtering

3 - API Query Parameters

4 - Complex Nested Conditions

Key Benefits

Cleaner Code – Eliminate repetitive conditional logic
Type Safety – Compile-time checks with IntelliSense support
Performance – Translates directly to optimized SQL queries
Maintainability – Centralized filter logic, easier to test and extend
Flexibility – Works seamlessly with existing Entity Framework code

Built For Modern .Net

WhereDynamic is built on .NET 8+, fully compatible with Entity Framework Core, and designed with performance and developer experience in mind. Whether you're building REST APIs, GraphQL endpoints, or complex reporting systems, it adapts to your needs.