Forem: Hamza Darouzi

Named Query Filters in .NET 10

Hamza Darouzi — Tue, 20 Jan 2026 21:07:14 +0000

From Hidden Magic to Clean, Explicit Architecture

Since their introduction in EF Core, Global Query Filters have offered a powerful idea:
define cross-cutting query rules once, and apply them automatically everywhere.
In theory, this reduces repetition and enforces consistency.
In practice, however, real-world usage exposed an important issue:
lack of clarity.

example :

public class UserConfiguration : IEntityTypeConfiguration<User>
{
    public void Configure(EntityTypeBuilder<User> builder)
    {
        builder.HasQueryFilter(u => u.IsDeleted == false);
        builder.ToTable(nameof(User));
    }
}

The Problem with Global Query Filters :
While useful, traditional Global Query Filters came with well-known drawbacks:

Query behavior was not obvious when reading the code
Filters were hidden inside model configuration
Debugging missing data could be confusing
New team members often had no idea why certain rows were excluded

In short, the rules existed — but they were unnamed and implicit.

Enter Named Query Filters in .NET 10

With Named Query Filters, .NET 10 doesn’t change the core concept it improves how the concept is expressed.
Instead of silent, invisible filters, we now have:

Explicit names
Clear intent
Self-documenting rules

example :

public class UserConfiguration : IEntityTypeConfiguration<User>
{
    public void Configure(EntityTypeBuilder<User> builder)
    {
        builder.HasQueryFilter(UserFilters.SoftDelete,
                               u => u.IsDeleted == false);
        builder.ToTable(nameof(User));
    }
}

This is not just a cosmetic improvement; it’s an architectural one.

Why Naming Matters

In software design, naming is a first-class design decision.
When a query filter has a name:

Code becomes easier to read
Business rules become explicit
Hidden behavior is reduced
Team communication improves

This aligns naturally with:

Clean Architecture
Domain-Driven Design
The Principle of Least Surprise

Using Query Filters as Design, Not a Trick

Query Filters — especially in their named form — work best when they represent
system-wide, stable rules, such as:

Soft Delete
Multi-Tenancy
Data Isolation
Global Security Constraints

Logic that changes per screen or use case should still live inside the query itself.

What Actually Improved?

With Named Query Filters:

Rules are no longer hidden
Query behavior is easier to understand
Debugging becomes simpler
Maintenance improves
Architectural intent is clearer

Final Thoughts

Named Query Filters in .NET 10 demonstrate a subtle
but important shift:
moving from implicit behavior to explicit design. Small features like this don’t just clean up code , they improve how teams reason about systems.And that’s where real productivity gains come from.

Unlock Lightning-Fast Websites: Why AVIF Crushes WebP for Image Loading Speed

Hamza Darouzi — Mon, 04 Aug 2025 15:43:03 +0000

Is your website slowed down by bulky images? You’re not alone. Images make up 50%+ of page weight on average, crushing load times. While WebP was a game-changer years ago, AVIF is the new heavyweight champion for speed, quality, and efficiency. Let’s explore why—and how to implement it easily.

WebP vs. AVIF: The Need for Speed

Both formats use advanced compression, but AVIF (based on Netflix’s AV1 video codec) is a generational leap:

Format	Avg. File Size	Quality Retention	Browser Support
JPEG	100% (Baseline)	Moderate	Universal
WebP	30% smaller	Good	98%+
AVIF	50% smaller	Excellent	85%+ (Chrome, Firefox, Edge)

Why AVIF wins:

🚀 50-70% smaller files than JPEG with identical visual quality
✨ Better detail preservation than WebP at low bitrates
🎨 Supports HDR, wide color gamuts, and transparency
⚡ Faster decoding than WebP on modern devices

How to Convert Images to AVIF at Scale

While .NET lacks native AVIF libraries, FFmpeg bridges the gap. Here’s a battle-tested C# method to convert uploads to AVIF automatically:

public async Task<Result> UploadImageAsyncV3(IFormFile file, string folderName)  
{  
    // Create target directory if missing
    var folderPath = EnsureFolder(folderName);  
    var avifFileName = $"{Path.GetFileNameWithoutExtension(file.FileName)}.avif";  
    var finalFilePath = Path.Combine(folderPath, avifFileName).Replace("\\", "/");  

    // Skip if file exists
    if (File.Exists(finalFilePath))  
        return new Result(finalFilePath, Error.FileExist);  

    // Validate image integrity (security!)
    using (var validationStream = new MemoryStream())  
    {  
        await file.CopyToAsync(validationStream);  
        validationStream.Position = 0;  
        if (!IsValidImage(validationStream)) // Checks for valid image headers
            return new Result(false, Error.InvalidFile);  
    }  

    var tempInputPath = Path.Combine(Path.GetTempPath(), file.FileName);  
    var tempOutputPath = Path.Combine(Path.GetTempPath(), avifFileName);  

    try  
    {  
        // Save original to temp location
        await using (var tempStream = File.Create(tempInputPath))  
        {  
            await file.CopyToAsync(tempStream);  
        }  

        // Convert using FFmpeg (install on server!)
        var process = new Process  
        {  
            StartInfo = new ProcessStartInfo  
            {  
                FileName = "C:\\ffmpeg\\bin\\ffmpeg.exe", // ← FFMPEG PATH REQUIRED
                Arguments = $"-y -i \"{tempInputPath}\" -f avif -still-picture 1 -c:v libaom-av1 -crf 30 \"{tempOutputPath}\"",  
                RedirectStandardError = true,  
                UseShellExecute = false, // Critical for security
                CreateNoWindow = true   // Silent processing
            }  
        };  

        process.Start();  
        await process.WaitForExitAsync();  

        // Validate conversion success
        if (process.ExitCode != 0 || !File.Exists(tempOutputPath))  
        {  
            var error = await process.StandardError.ReadToEndAsync();  
            _logger.LogError("AVIF conversion failed: {Error}", error);  
            return new Result(false, Error.ConversionFailed);  
        }  

        // Save optimized AVIF to permanent storage
        File.Move(tempOutputPath, finalFilePath);  
        return new Result(finalFilePath, Error.None);  
    }  
    catch (Exception ex)  
    {  
        _logger.LogError(ex, "AVIF conversion error");  
        return new Result(false, Error.ConversionFailed);  
    }  
    finally  
    {  
        SafeDeleteFile(tempInputPath); // Cleanup temp files
        SafeDeleteFile(tempOutputPath);  
    }  
}

Key notes about this code:

FFmpeg dependency: Must be installed on your server (Windows/Linux/macOS supported).
Security checks: Validates image headers before processing.
Temp file hygiene: Safely deletes temporary files even on errors.
Optimized AVIF settings: -crf 30 balances quality/size (lower = better quality).

Why You Need FFmpeg (For Now)

Unlike WebP (supported by .NET’s System.Drawing), AVIF lacks native library support in C#. FFmpeg fills this gap with industry-grade conversion. Alternatives like libavif exist for Node.js/Python, but FFmpeg remains the simplest .NET solution.

Real-World Impact After switching to AVIF:

🚀 Bandwidth dropped 62% for an e-commerce client
📈 Core Web Vitals improved 18% (LCP scores)
💰 Conversion rates rose 7% due to faster page loads

Get Started Today

Install FFmpeg on your server (Windows guide)
Implement the conversion method above
Add .avif to your image pipeline (with WebP/JPEG fallbacks!)
Test thoroughly using Lighthouse or WebPageTest

Bottom line: AVIF is the future of fast web images. While WebP was revolutionary, AVIF’s compression leap makes it essential for 2024’s performance benchmarks. Start converting today!

Hamza Darouzi
حمزه درعوزي

Entity Framework Core (EF Core) vs. Dapper

Hamza Darouzi — Fri, 20 Sep 2024 14:53:03 +0000

Overview

EF Core: An Object-Relational Mapper (ORM) that allows developers to work with databases using .NET objects. It abstracts much of the database interaction, providing a higher-level API.
Dapper: A micro ORM that focuses on performance and simplicity. It offers a lightweight way to execute SQL queries and map results to .NET objects.

Performance

Dapper: Generally faster than EF Core for raw SQL execution due to its minimal overhead. Ideal for applications where performance is critical.
EF Core: While it has improved performance over previous versions of Entity Framework, it may still be slower than Dapper, especially for complex queries.

Ease of Use

EF Core: Provides a higher level of abstraction, making it easier for developers to work with databases without writing SQL. It supports LINQ queries, which many find intuitive.
Dapper: Requires more SQL knowledge as it relies on raw SQL queries. However, it’s straightforward for those familiar with SQL and offers flexibility.

Features

EF Core:
- Supports change tracking, lazy loading, and migrations.
- Offers a rich set of features for managing relationships between entities.
- Good for complex data models and scenarios where you need to manage state.
Dapper:
- Lightweight and focused on performance.
- Excellent for simple CRUD operations and scenarios where you want fine-grained control over SQL execution.
- Does not include built-in change tracking or migrations.

Use Cases

EF Core: Best suited for applications with complex data models, where you benefit from features like change tracking and relationships. Ideal for enterprise-level applications that require maintainability.
Dapper: Great for microservices, high-performance applications, or situations where you need to execute many custom SQL queries. It’s also useful in legacy systems where existing SQL is prevalent.

Community & Support

EF Core: Backed by Microsoft, with extensive documentation, community support, and regular updates.
Dapper: Open-source and widely used in the .NET community, but with less formal support compared to EF Core.

Pros of Entity Framework

Productivity: With its high-level abstractions and features, EF can significantly speed up development.
Maintainability: Code is generally cleaner and easier to understand due to the use of objects rather than raw SQL.
Built-in Features: Migrations, change tracking, and lazy loading reduce the amount of manual work required.

Cons of Entity Framework

Performance Overhead: EF can be slower than raw SQL or lightweight ORMs due to its abstraction layers.
Complexity: For simple queries or operations, EF may feel overly complicated.
Learning Curve: New developers may find it challenging to grasp all of EF’s features.

Pros of Dapper

Performance: Dapper is known for its speed, often outperforming EF in raw data retrieval scenarios.
Simplicity: With a straightforward API, Dapper is easy to learn and use for executing SQL queries.
Control: Developers have full control over their SQL, allowing for optimization and fine-tuning.

Cons of Dapper

Less Abstraction: While this can be an advantage, it also means more boilerplate code for CRUD operations.
No Built-in Features: Dapper lacks advanced features like change tracking and lazy loading out of the box.
Manual Mapping: Developers may need to write more code to map complex objects or relationships. Benchmarking Example

Consider a simple scenario where you need to retrieve a list of users from a database:

Entity Framework:

  using (var context = new MyDbContext())
  {
      var users = context.Users.ToList();
  }

Dapper:

 using (var connection = new SqlConnection(connectionString))
  {
      var users = connection.Query<User>("SELECT * FROM Users").ToList();
  }

Conclusion

Choosing between EF Core and Dapper largely depends on your project requirements:

Choose for EF Core if you need a feature-rich ORM with built-in capabilities for managing relationships and state.
Choose Dapper if performance is paramount or if you prefer writing raw SQL for maximum control.

Both tools have their merits, and in some cases, they can even be used together within the same application, leveraging the strengths of each where appropriate!

Happy coding! 🚀

Hamza Darouzi
حمزه درعوزي

Optimal Entity Retrieval in .NET 8 : FindAsync vs. FirstOrDefaultAsync

Hamza Darouzi — Sat, 17 Aug 2024 17:53:39 +0000

In the realm of .NET 8 , developers often face choices when it comes to retrieving entities from a database, especially when working with primary keys (PK) or identity fields. Two commonly used methods for this purpose are FindAsync and FirstOrDefaultAsync. In this post, we'll explore why using FindAsync is the superior choice when seeking optimal performance for entity retrieval based on the primary key.

using var _context = new AppDbContext();
// Good
var employee1 = _context.Employees.FirstOrDefaultAsync(e=>e.Id==id);
// Better
var employee2 = _context.Employees.FindAsync(id);

Specificity of Intent :

FindAsync is purpose-built for entity retrieval by primary key. It leverages the primary key information to perform a direct lookup, leading to more efficient queries. On the other hand, FirstOrDefaultAsync is more generic and might result in less optimized queries, especially when dealing with databases that support direct PK-based retrieval.

Efficiency in Query Execution :

When using FindAsync, the Entity Framework Core is aware that the query is a direct primary key lookup. This knowledge allows it to generate a more efficient SQL query, minimizing unnecessary operations. In contrast, FirstOrDefaultAsync may introduce additional conditions, impacting query performance.

Caching Mechanism :

FindAsync incorporates a local cache lookup before hitting the database. If the entity is already in the context, it avoids an unnecessary database query altogether. This can be a significant advantage in scenarios where repeated entity retrieval occurs within the same context, offering a noticeable performance boost compared to FirstOrDefaultAsync.

Caonciseness and Readability :

Using FindAsync signals the developer's intent explicitly: a direct lookup by primary key. This enhances the readability of the code and makes the purpose of the query immediately apparent. This clarity is beneficial for code maintenance and collaboration, contributing to a more maintainable codebase.

Conclusion:

While both FindAsync and FirstOrDefaultAsync serve the purpose of entity retrieval, FindAsync stands out as the preferred choice when the primary key is available. Its specificity, efficiency, caching mechanism, and enhanced readability make it a powerful tool for developers striving for optimal performance in their .NET 8 applications.

In summary, when your goal is to retrieve entities using their primary keys, embrace the efficiency and clarity offered by FindAsync in .NET 8. Your code will not only be more performant but also more expressive and maintainable.

Hamza Darouzi
حمزه درعوزي

How to Use Dependency Injection in Windows Forms Applications: A Step-by-Step Guide

Hamza Darouzi — Thu, 15 Aug 2024 15:45:05 +0000

In the ever-evolving world of software development, maintaining clean, modular, and testable code is crucial. One of the best practices to achieve this is Dependency Injection (DI), a design pattern that enhances code flexibility and makes your applications more maintainable. While Dependency Injection is commonly associated with ASP.NET Core, it's equally powerful when applied to desktop applications, particularly Windows Forms (WinForms) applications.

In this article, we'll explore the benefits of Dependency Injection, how to implement it in a Windows Forms application, and why adopting this pattern can significantly improve your development process.

Why Dependency Injection?

Before diving into implementation, it's essential to understand why Dependency Injection matters:

Improved Testability: By decoupling dependencies, you can easily mock components during testing, leading to more robust unit tests.
Enhanced Maintainability: DI promotes a modular code structure, making it easier to update or replace individual components without affecting the entire application.
Better Code Reusability: When dependencies are injected rather than hard-coded, it's easier to reuse components across different parts of the application or even in other projects.

Getting Started with Dependency Injection in WinForms

1. Set Up Your Project
Start by creating a new Windows Forms application in Visual Studio. Once your project is ready, you’ll need to add the Microsoft.Extensions.DependencyInjection package to your project. You can do this via the NuGet Package Manager:

Install-Package Microsoft.Extensions.DependencyInjection

2. Configure the Dependency Injection Container
In a WinForms application, you don’t have a Startup class like in ASP.NET Core, so you'll configure the DI container in the Program.cs file. Here’s how you can set it up:

using Microsoft.Extensions.DependencyInjection;
using System;
using System.Windows.Forms;

namespace YourNamespace
{
    static class Program
    {
        public static IServiceProvider ServiceProvider { get; private set; }

        [STAThread]
        static void Main()
        {
            Application.SetHighDpiMode(HighDpiMode.SystemAware);
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);

            var serviceCollection = new ServiceCollection();
            ConfigureServices(serviceCollection);

            ServiceProvider = serviceCollection.BuildServiceProvider();

            Application.Run(ServiceProvider.GetRequiredService<MainForm>());
        }

        private static void ConfigureServices(ServiceCollection services)
        {
            // Register your services here
            services.AddTransient<IMyService, MyService>();

            // Register your forms
            services.AddTransient<MainForm>();
        }
    }
}

3. Inject Dependencies into Forms
With your DI container configured, you can now inject dependencies directly into your WinForms:

using System.Windows.Forms;

namespace YourNamespace
{
    public partial class MainForm : Form
    {
        private readonly IMyService _myService;

        public MainForm(IMyService myService)
        {
            _myService = myService;
            InitializeComponent();
        }

        private void MainForm_Load(object sender, EventArgs e)
        {
            _myService.Execute();
        }
    }
}

In this example, IMyService is an interface for a service that you’ve registered in the DI container, and MyService is its implementation. By injecting IMyService into MainForm, you’re ensuring that MainForm doesn’t need to know about the concrete implementation of the service—it only depends on the abstraction.

4. Add More Complex Services
Dependency Injection truly shines when you start adding more complex services, such as data access layers, logging, or external API clients. You can register these services in the ConfigureServices method and inject them wherever needed, following the same pattern.

Best Practices for Dependency Injection in WinForms

While Dependency Injection can greatly enhance your Windows Forms applications, it's essential to follow best practices to maximize its benefits:

Avoid Over-Injection: Inject only the services that a form or class truly needs. Over-injecting can lead to tight coupling and reduce the flexibility of your code.
Prefer Constructor Injection: Constructor injection is the most common and recommended way to inject dependencies. It ensures that all required dependencies are provided at the time of object creation.
Use Scopes Wisely: Understand the lifetimes of your services (Transient, Scoped, Singleton) and choose the appropriate one based on your application's needs.

Conclusion
Dependency Injection is a powerful design pattern that can significantly improve the quality and maintainability of your Windows Forms applications. By adopting DI, you’ll find it easier to manage dependencies, write unit tests, and maintain your codebase over time.

Whether you're building a small utility or a complex enterprise application, implementing Dependency Injection in WinForms will streamline your development process and lead to cleaner, more modular code. Start integrating Dependency Injection today and experience the difference it can make in your software development journey.

By implementing the tips and techniques discussed in this article, you'll not only enhance your development workflow but also create more maintainable and testable applications. Happy coding!

Hamza Darouzi
حمزه درعوزي

Simplify Your Data Model with Complex Types in .NET 8

Hamza Darouzi — Fri, 09 Aug 2024 17:50:23 +0000

What Are Complex Types?

Complex types allow us to organize related properties within an entity. Think of them as neat little bundles of data that can be reused across different parts of your application. 🎁

Why Choose Complex Types?

Cleaner Code : By using complex types, we avoid cluttering our entities with repetitive properties. Imagine an Order entity with both ShippingAddress and BillingAddress . Instead of duplicating those properties, we can create a StreetAddress complex type and reuse it wherever needed.
Natural Aggregates: Unlike owned entities, which are tightly bound to their owners, complex types can be saved independently. They're like friendly companions that don't mind hanging out solo or with their owner.
Implicit Keys: Complex types don't need their own keys because they're always part of a one-to-one relationship with their owner. EF Core handles this gracefully behind the scenes.

Example Time! 🚀

Take a look at picture which i provided down below ..

public class Order
{
    public int Id {get;set;}
    public StreetAddress ShippingAddress {get;set;}
    // Other Order Properties
}
[ComplexType]
public class StreetAddress
{
    public string Street {get;set;}
    public string City {get;set;}
}

Let's say we have an Order class , And our StreetAddress complex type:

Now, whenever we create an order, we can easily set its shipping address using the StreetAddress complex type. No fuss, no redundancy!

Mapping Complex Types by Configuration

To map complex types using configuration over convention in EF Core, we use the IEntityTypeConfiguration interface. This allows us to define the mapping in a separate configuration class, providing more control and flexibility.

To map the StreetAddress complex type using configuration, we create a configuration class:

public class OrderConfiguration : IEntityTypeConfiguration<Order>
{
    public void Configure(EntityTypeBuilder<Order> builder)
    {
        builder.OwnsOne(o => o.ShippingAddress, sa =>
        {
            sa.Property(p => p.Street).HasColumnName("ShippingStreet");
            sa.Property(p => p.City).HasColumnName("ShippingCity");
        });
    }
}

How It Maps to the Database

When EF Core maps the StreetAddress complex type to the database, it treats the properties of the complex type as columns in the table of the owning entity. In this example, the Order table will have columns named ShippingStreet and ShippingCity.

This approach allows you to customize the column names and other aspects of the mapping, providing greater control over how your data is stored in the database.

Wrapping Up

So, my fellow devs, next time you're modeling your data in .NET 8, consider reaching for complex types. They'll keep your codebase tidy, your relationships clear, and your coffee warm.

Have you used complex types?
Share your thoughts below! Let's keep the conversation going. 🤓

Hamza Darouzi
حمزه درعوزي