DEV Community: Krzysztof Begiedza

Infamous N+1 Query Problem with Entity Framework Core

Krzysztof Begiedza — Wed, 13 Nov 2024 08:14:00 +0000

Abstract

When working with Entity Framework Core, you typically interact with your database using LINQ queries to retrieve and manipulate data. However, sometimes when fetching related entities, you may encounter performance issues. Your application might slow down as your database grows, or perhaps you've run into the infamous N+1 query problem.

Introduction to the N+1 Query Problem

The N+1 query problem is a common performance issue that occurs when using an ORM like Entity Framework Core. This issue arises when you fetch a collection of entities (the "N" entities) and then lazily load related entities one by one (the "+1" entities). For each entity in the collection, a separate query is executed to fetch the related data, resulting in N+1 queries being sent to the database.

Why Does the N+1 Query Problem Occur in Entity Framework Core?

This problem typically occurs when lazy loading is enabled, or when related entities are not explicitly loaded in a single query. By default, Entity Framework Core does not enable lazy loading unless configured using UseLazyLoadingProxies(). When lazy loading is turned on, related entities are fetched only when accessed for the first time.

For example:

// Fetch all guilds
var guilds = context.Guilds.ToList();

// Accessing navigation property triggers additional queries
foreach (var guild in guilds)
{
    // Execute N additional queries (one per guild)
    foreach (var player in guild.Players)
    {
        Console.WriteLine(player.Name);
    }
}

In many cases, the N+1 issue arises because developers forget to use eager loading. Without it, Entity Framework Core does not fetch related entities upfront, leading to multiple queries when accessing navigation properties.

public async Task FetchWithLazyLoadingAsync()
{
    var guilds = await context.Guilds.ToListAsync();

    foreach (var guild in guilds)
    {
        logger.LogInformation("Guild:\t{GuildName} have Players:\t{PlayersCount}", guild.Name, guild.Players.Count);
    }
}

The above code results in N+1 queries, where N is the number of guilds in the database:

06:44:49:503 info: Microsoft.EntityFrameworkCore.Database.Command[20101]
      Executed DbCommand (1ms) [Parameters=[@__get_Item_0='?' (DbType = Guid)], CommandType='Text', CommandTimeout='30']
      SELECT "p"."Id", "p"."GuildId", "p"."Username"
      FROM "Players" AS "p"
      WHERE "p"."GuildId" = @__get_Item_0
06:44:49:523 info: DatabasesSandbox.Services.GameMonitorService[0]
      Guild:    Guild 16 have Players:  100
06:44:50:696 info: Microsoft.EntityFrameworkCore.Database.Command[20101]
      Executed DbCommand (0ms) [Parameters=[@__get_Item_0='?' (DbType = Guid)], CommandType='Text', CommandTimeout='30']
      SELECT "p"."Id", "p"."GuildId", "p"."Username"
      FROM "Players" AS "p"
      WHERE "p"."GuildId" = @__get_Item_0
06:44:50:709 info: DatabasesSandbox.Services.GameMonitorService[0]
      Guild:    Guild 18 have Players:  100

Strategies to Optimize Database Performance with Entity Framework Core

To mitigate the N+1 query problem and optimize database performance, consider using the following strategies:

1. Eager Loading

Eager loading retrieves related entities along with the main entity in a single query, reducing the number of database round trips. Use the Include method to specify which navigation properties to load:

public async Task FetchWithEagerLoadingAsync()
{
    var guilds = await context.Guilds
                              .Include(g => g.Players)
                              .ToListAsync();

    foreach (var guild in guilds)
    {
        logger.LogInformation("Guild:\t{GuildName} have Players:\t{PlayersCount}", guild.Name, guild.Players.Count);
    }
}

This method results in only one query:

06:47:45:534 info: Microsoft.EntityFrameworkCore.Database.Command[20101]
      Executed DbCommand (0ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
      SELECT "g"."Id", "g"."Name", "p"."Id", "p"."GuildId", "p"."Username"
      FROM "Guilds" AS "g"
      LEFT JOIN "Players" AS "p" ON "g"."Id" = "p"."GuildId"
      ORDER BY "g"."Id"
06:47:48:820 info: DatabasesSandbox.Services.GameMonitorService[0]
      Guild:    Guild 8 have Players:   100
06:47:49:649 info: DatabasesSandbox.Services.GameMonitorService[0]
      Guild:    Guild 9 have Players:   100
06:47:50:509 info: DatabasesSandbox.Services.GameMonitorService[0]
      Guild:    Guild 25 have Players:  100
06:47:51:371 info: DatabasesSandbox.Services.GameMonitorService[0]
      Guild:    Guild 6 have Players:   100

2. Explicit Loading

Explicit loading allows you to load related entities on demand. This can be done using the Entry method:

public async Task FetchWithExplicitLoadingAsync()
{
    var explicitGuild = context.Guilds.OrderBy(g => g.Name).First();
    await context.Entry(explicitGuild )
                 .Collection(b => b.Players).LoadAsync();

    logger.LogInformation("Guild:\t{GuildName} have Players:\t{PlayersCount}", explicitGuild.Name, explicitGuild.Players.Count);

    var guilds = await context.Guilds.OrderBy(g => g.Name).ToListAsync();

    foreach (var guild in guilds)
    {
        logger.LogInformation("Guild:\t{GuildName} have Players:\t{PlayersCount}", guild.Name, guild.Players.Count);
    }
}

Explicit loading allows you to control when related entities are loaded, avoiding unnecessary queries. In logs below you can see that only one query is executed to fetch related entities for the specified guild, but all other guilds were not loaded and additional queries were executed to fetch related entities for them:

07:18:22:634 info: Microsoft.EntityFrameworkCore.Database.Command[20101]
      Executed DbCommand (0ms) [Parameters=[@__get_Item_0='?' (DbType = Guid)], CommandType='Text', CommandTimeout='30']
      SELECT "p"."Id", "p"."GuildId", "p"."Username"
      FROM "Players" AS "p"
      WHERE "p"."GuildId" = @__get_Item_0
07:18:30:019 info: DatabasesSandbox.Services.GameMonitorService[0]
      Guild:    Guild 0 have Players:   100
07:18:31:043 info: Microsoft.EntityFrameworkCore.Database.Command[20101]
      Executed DbCommand (0ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
      SELECT "g"."Id", "g"."Name"
      FROM "Guilds" AS "g"
      ORDER BY "g"."Name"
07:18:34:959 info: DatabasesSandbox.Services.GameMonitorService[0]
      Guild:    Guild 0 have Players:   100
07:18:36:855 info: Microsoft.EntityFrameworkCore.Database.Command[20101]
      Executed DbCommand (0ms) [Parameters=[@__get_Item_0='?' (DbType = Guid)], CommandType='Text', CommandTimeout='30']
      SELECT "p"."Id", "p"."GuildId", "p"."Username"
      FROM "Players" AS "p"
      WHERE "p"."GuildId" = @__get_Item_0
07:18:36:869 info: DatabasesSandbox.Services.GameMonitorService[0]
      Guild:    Guild 1 have Players:   100
07:18:38:634 info: Microsoft.EntityFrameworkCore.Database.Command[20101]
      Executed DbCommand (0ms) [Parameters=[@__get_Item_0='?' (DbType = Guid)], CommandType='Text', CommandTimeout='30']
      SELECT "p"."Id", "p"."GuildId", "p"."Username"
      FROM "Players" AS "p"
      WHERE "p"."GuildId" = @__get_Item_0
07:18:38:648 info: DatabasesSandbox.Services.GameMonitorService[0]
      Guild:    Guild 10 have Players:  100

3. Query Projection

Query projection involves selecting only the required data from the database, reducing the amount of data transferred over the network. You can use the Select method to project the query results into a custom type or an anonymous type. For example:

public async Task FetchWithQueryProjectionAsync()
{
    var guilds = await context.Guilds
        .Select(g => new
        {
            Name = g.Name,
            Players = g.Players.Select(p => p.Username).ToList()
        })
        .ToListAsync();

    foreach (var guild in guilds)
    {
        logger.LogInformation("Guild:\t{GuildName} have Players:\t{PlayersCount}", guild.Name, guild.Players.Count);
    }
}

By projecting the query results, you can optimize database performance by fetching only the necessary data. This can help reduce the number of queries and improve the efficiency of your application as you can observe in the logs:

07:06:56:051 info: Microsoft.EntityFrameworkCore.Database.Command[20101]
      Executed DbCommand (0ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
      SELECT "g"."Name", "g"."Id", "p"."Username", "p"."Id"
      FROM "Guilds" AS "g"
      LEFT JOIN "Players" AS "p" ON "g"."Id" = "p"."GuildId"
      ORDER BY "g"."Id"
07:07:06:805 info: DatabasesSandbox.Services.GameMonitorService[0]
      Guild:    Guild 8 have Players:   100
07:07:07:965 info: DatabasesSandbox.Services.GameMonitorService[0]
      Guild:    Guild 9 have Players:   100
07:07:08:980 info: DatabasesSandbox.Services.GameMonitorService[0]
      Guild:    Guild 25 have Players:  100

4. (bonus) Disable Lazy Loading

If lazy loading is not required in your application, you can disable it to prevent unexpected behavior and minimize risk of the N+1 query problem.
You can do it globally by setting the UseLazyLoadingProxies option to false in the Entity Framework Core context configuration. For example:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    optionsBuilder.UseLazyLoadingProxies(false);
}

Conclusion

The N+1 query problem is a well-known performance issue in Entity Framework Core that can affect the efficiency of your database queries. By implementing strategies like eager loading, explicit loading, query projection, and disabling lazy loading, you can optimize your application’s performance. Understanding these techniques can significantly improve your application’s responsiveness and database efficiency.

Secure Your Data with Entity Framework Core Encryption

Krzysztof Begiedza — Mon, 30 Sep 2024 12:44:17 +0000

Abstract

Storing sensitive data in a database is not an easy task. Many things can go wrong, especially if proper precautions aren’t taken. Sensitive information, such as personal details or financial records, can become vulnerable to unauthorized access if encryption and security measures aren’t carefully implemented.

When it comes to encrypting and decrypting data in an application, ASP.NET Core provides a brilliant option for handling encryption with the powerful DataProtection API. Alternatively, you can implement custom encryption logic tailored to your application's requirements. However, the challenge is not only encrypting and decrypting the data but also managing how this encrypted data is stored and retrieved efficiently from the database.

There are multiple ways to handle the storage and retrieval of encrypted data in Entity Framework Core. One common approach is to use backing fields, where encryption and decryption are handled on the fly when the data is accessed via property getters or setters. This way, the sensitive data remains encrypted while at rest in the database but is decrypted just in time when needed by the application.

public record PlayerProfile(ICryptographyService cryptographyService)
{
    private string _email;
    private string _realName;

    public string Email
    {
        get => cryptographyService.Decrypt(_email);
        set => _email = cryptographyService.Encrypt(value);
    }

    public string RealName
    {
        get => cryptographyService.Decrypt(_realName);
        set => _realName = cryptographyService.Encrypt(value);
    }
}

Another more robust approach leverages Entity Framework Core's ValueConverters, which can be registered at the model creation level. Value converters allow you to specify how data is transformed when being read from or written to the database, making them ideal for encrypting sensitive data at the column level without affecting the rest of the business logic.

In this post, I would like to share a flexible solution based on the second approach to encrypt and decrypt columns in your database.

Implementation

Suppose you have a player profile entity in your application that contains sensitive information, such as a player's real name and email address. To comply with data protection regulations like GDPR, as well as to ensure the privacy of your users, this information must be securely stored in an encrypted format within the database.

public record PlayerProfile
{
    public required Guid Id { get; init; }

    public required string Email { get; init; }

    public required string RealName { get; init; }
}

To achieve this, we can implement encryption using a value converter that automatically encrypts the data before it is written to the database and decrypts it when it is retrieved. To perform encryption and decryption, we will use a custom ICryptographyService interface that provides methods for encrypting and decrypting data. For simplicity, we will use a simple reverse encryption algorithm in this example.

public interface ICryptographyService
{
    string Encrypt(string data);

    string Decrypt(string data);
}

public class ReverseCryptographyService : ICryptographyService
{
    public string Encrypt(string value)
    {
        ArgumentNullException.ThrowIfNull(value);
        var sb = new StringBuilder();

        foreach (var c in value.Reverse())
            sb.Append(c);

        return sb.ToString();
    }

    public string Decrypt(string value)
    {
        ArgumentNullException.ThrowIfNull(value);
        var sb = new StringBuilder();

        foreach (var c in value.Reverse())
            sb.Append(c);

        return sb.ToString();
    }
}

Next, we should register our ICryptographyService implementation in the DI container in the Startup class.

var builder = WebApplication.CreateBuilder(args);
// ...
builder.Services.AddSingleton<ICryptographyService, ReverseCryptographyService>();

Now, we are ready to implement the EncryptedConverter class that will be used to encrypt and decrypt the data. The EncryptedConverter class inherits from the ValueConverter class provided by Entity Framework Core. It takes an instance of the ICryptographyService interface in its constructor and uses it to encrypt and decrypt the data.

public class EncryptedConverter : ValueConverter<string, string>
{
    public EncryptedConverter(ICryptographyService cryptographyService, ConverterMappingHints? mappingHints = null)
        : base(v => cryptographyService.Encrypt(v),
               v => cryptographyService.Decrypt(v),
               mappingHints) { }
}

From now on, we can use fluent configuration or define a new attribute to mark properties that need to be encrypted. Let's start with the first approach.

Fluent configuration

To use the EncryptedConverter class, we need to configure it in the OnModelCreating method of the DbContext class. We can do this by calling the HasConversion method on the PropertyBuilder instance for each property that needs to be encrypted. To keep DbContext clean, we can create a fluent configuration for our PlayerProfile.

public class PlayerProfileConfiguration : IEntityTypeConfiguration<PlayerProfile>
{
    private readonly ICryptographyService _cryptographyService;

    public PlayerProfileFluentConfiguration(ICryptographyService cryptographyService)
    {
        _cryptographyService = cryptographyService;
    }

    public void Configure(EntityTypeBuilder<PlayerProfile> builder)
    {
        var converter = new EncryptedConverter(_cryptographyService);

        builder.HasKey(b => b.Id);

        builder.Property(b => b.Email)
            .IsRequired()
            .HasConversion(converter);

        builder.Property(b => b.RealName)
            .IsRequired()
            .HasConversion(converter);
    }
}

Don't forget to register your configuration in the OnModelCreating method of your DbContext class.

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);

    modelBuilder.ApplyConfiguration(new PlayerProfileConfiguration(_cryptographyService));
}

Attribute-based configuration

If you prefer to use attributes to mark properties that need to be encrypted, you can create a custom attribute and use it to decorate the properties in your entity class.

[AttributeUsage(AttributeTargets.Property)]
public sealed class EncryptedAttribute : Attribute
{
}

Next step is to add our newly created attribute to the properties that need to be encrypted.

public record PlayerProfile
{
    [Required]
    public required Guid Id { get; init; }

    [Required]
    [Encrypted]
    public required string Email { get; init; }

    [Required]
    [Encrypted]
    public required string RealName { get; init; }
}

Then we can scan all properties in the OnModelCreating method of the DbContext class and apply the EncryptedConverter to those properties that are marked with the EncryptedAttribute.

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    base.OnModelCreating(modelBuilder);

    var stringType = typeof(string);
    var encryptedAttribute = typeof(EncryptedAttribute);
    var converter = new EncryptedConverter(_cryptographyService);

    foreach (var entityType in modelBuilder.Model.GetEntityTypes())
    {
        foreach (var property in entityType.GetProperties())
        {
            if (!IsDiscriminator(property)
                && property.ClrType == stringType
                && property.PropertyInfo is not null)
            {
                var attributes = property.PropertyInfo.GetCustomAttributes(encryptedAttribute, false);

                if (attributes.Length != 0)
                {
                    property.SetValueConverter(converter);
                }
            }
        }
    }

    bool IsDiscriminator(IMutableProperty property) => property.Name == "Discriminator";
}

One gotcha with this approach is ensuring that the scanned property is not a discriminator column. The discriminator column is used by EF Core to store information about the entity type in Table Per Hierarchy (TPH) inheritance scenarios.

Results

Finally, let's see how the conversion of PlayerProfile works!

After inserting a few new records into the database, we can see that the data is stored in an encrypted format.

Id	Email	RealName
035de6f3-9c58-4c39-abfe-997f172cef0e	moc.elpmaxe@divaD	senoJ divaD
052d8c82-a05f-4590-b444-8590829ab1e1	moc.elpmaxe@eilrahC	smailliW eilrahC
2a10c13e-27e2-4a0f-9e87-f1eed8b15354	moc.elpmaxe@evE	nworB evE
9f1eccaa-5574-411e-8b40-38f362b650aa	moc.elpmaxe@ecilA	htimS ecilA
fcfcd03c-d0d1-4bba-ae24-a97b829ee1b8	moc.elpmaxe@boB	nosnhoJ boB

When we retrieve the data from the database, the encrypted values should be automatically decrypted. Let's test this scenario by querying and listing items in our store.

info: Encrypto.DemoService[0]
      Profile:
      Id:       520f79c9-a16e-47ce-9ede-6aeeac857ac4
      Email:    Eve@example.com
      Name:     Eve Brown
info: Encrypto.DemoService[0]
      Profile:
      Id:       669e4809-0bcb-4523-8bc9-54c7fec8b752
      Email:    Bob@example.com
      Name:     Bob Johnson
info: Encrypto.DemoService[0]
      Profile:
      Id:       8b68946a-b490-47df-a9f6-fcc7c481de6a
      Email:    Charlie@example.com
      Name:     Charlie Williams
info: Encrypto.DemoService[0]
      Profile:
      Id:       8c7f41a7-bb6f-4297-b17f-612a6e8881a4
      Email:    Alice@example.com
      Name:     Alice Smith
info: Encrypto.DemoService[0]
      Profile:
      Id:       f21dcba3-40e1-4fa4-9239-e8bbf2532928
      Email:    David@example.com
      Name:     David Jones

Conclusion

Securing sensitive data is crucial for both user privacy and legal compliance. By utilizing value converters in Entity Framework Core, you can efficiently encrypt and decrypt data stored in your database columns with minimal overhead.

Whether you use the built-in DataProtection API or implement your own encryption service, these two approaches are providing a flexible and powerful solution for handling encrypted data at scale.

Feature toggle management in .NET Core

Krzysztof Begiedza — Wed, 05 Jun 2024 06:04:00 +0000

The following article is available on my blog here.

Abstract

When working with a complex system, especially in a CI/CD environment, feature toggles, also known as feature flags, are used to deliver and test new changes without compromising the entire application for every user.

There are several techniques for implementing feature toggles, such as storing configurations in a file or database, or using an external service with a GUI for management. In this article, we will focus on Microsoft's official open-source package called Microsoft.FeatureManagement (along with its companion package Microsoft.FeatureManagement.AspNetCore designed for use with ASP.NET) for managing features. You can find the package on NuGet here. This package provides native integration with .NET and utilizes the standard IConfiguration interface, allowing you to use various configuration providers like Azure App Configuration. Using this package is a great starting point for patterns like: beta access, opt-in features or dark deployments.

Setup

For simplicity in this tutorial, we will focus on using appsettings.json as our configuration source. However, it's important to note that you can use any IConfiguration compatible provider to define your feature flags.

Let's jump right into a freshly created application using dotnet new worker. For the purpose of this demo, we will be using an IHost-based worker, as our package seamlessly integrates with the built-in dependency injection framework, improving the quality of life for programmers and the scalability of the application.

The next step is to add a reference to our package. You can use the CLI command dotnet add package Microsoft.FeatureManagement, or you can directly copy and paste the package reference into your *.csproj file.

Basic usage

As mentioned earlier, we will utilize the built-in DI container. To add our feature management to the DI container while configuring services for the host, you can use the following code:

var host = Host.CreateDefaultBuilder(args)
               .ConfigureServices(services =>
               {
                   services.AddHostedService<Worker>();

                   services.AddFeatureManagement();
               })
               .Build();

This code adds feature toggle support to the DI builder. Now, let's proceed to consuming our feature settings.

To perform a feature check, you can use the following code snippet:

public class Worker : BackgroundService
{
    private readonly ILogger<Worker> _logger;
    private readonly IFeatureManager _featureManager;

    public Worker(ILogger<Worker> logger,
                  IFeatureManager featureManager)
    {
        _logger = logger;
        _featureManager = featureManager;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        if (await _featureManager.IsEnabledAsync("ExperimentalAlgorithm"))
        {
             _logger.LogInformation("I'm using some experimental algorithm!");

            // do experimental stuff...
        }
    }
}

In the example above, we are using the async keyword to avoid blocking and wait for the feature flag check to complete. This is particularly useful in scenarios where flag check might involve network or I/O operations that could introduce delays.

Finally, let's add the following JSON snippet to appsettings.json and give it a spin:

{
    // ...
    "FeatureManagement": {
        "ExperimentalAlgorithm": true
    }
}

As you can see in the example, we are adding new feature toggles as children of the FeatureManagement object in the project's appsettings.json. This allows us to check the state of a specific feature by referring to its name and passing it to the abstraction provided by the IFeatureManager interface, which represents the entire feature toggle system.

A good practice when working with feature flags is to maintain a single source of truth for our flags. This makes it easier to refactor and remove flags in the future. To achieve this, you can use an enum or a partial class with defined const string variables instead of using loose strings in multiple places. For example:

public static partial class FeatureFlags
{
    public const string ExperimentalAlgorithm = "ExperimentalAlgorithm";
}

Remember to plan ahead for the lifetime of your feature flags and remove them when they are no longer needed to avoid dead code.

Usage in ASP.NET Core

To fully utilize the potential of feature management in ASP.NET Core, we need to add the separate NuGet package Microsoft.FeatureManagement.AspNetCore to our project using the command dotnet add package Microsoft.FeatureManagement.

Once installed, we can easily enable or disable selected controllers using the FeatureGate attribute and previously used appsettings.json file.

[FeatureGate(FeatureFlags.ExperimentalAlgorithm)]
public class ExperimentalController()
{
    // ...
}

In the example above, the FeatureGate attribute is applied to the ExperimentalController class. This attribute allows us to control access to the entire controller based on the state of a specific feature flag. If the feature flag specified in FeatureFlags.ExperimentalAlgorithm is enabled in the appsettings.json, the controller will be accessible and active. If the feature flag is disabled or not present, the controller will be automatically bypassed.

Using the FeatureGate attribute provides a convenient way to control the visibility and behavior of specific controllers based on feature flags. This enables us to gradually roll out new features, conduct A/B testing, or enable experimental functionality in a controlled manner.

Filters

In addition, our feature management library also offers a powerful extensible filtering mechanism. With this capability, we can leverage various predefined filters, such as the TimeWindowFilter, to limit the availability of selected features based on a defined time window. Additionally, we can easily plan ahead and enable new features after a specific date by omitting the End parameter in the configuration.

To use the filtering feature, we need to register the appropriate filter in our DI container:

var host = Host.CreateDefaultBuilder(args)
               .ConfigureServices(services =>
               {
                   services.AddHostedService<Worker>();

                   services.AddFeatureManagement()
                           // Register TimeWindowFilter
                           .AddFeatureFilter<TimeWindowFilter>();
               })
               .Build();

Next, we need to configure the filter's parameters in our appsettings.json:

"FeatureManagement": {
    "ExperimentalAlgorithm": {
        "EnabledFor": [
            {
                "Name": "Microsoft.TimeWindow",
                "Parameters": {
                    "Start": "2023-05-24T17:00:00.0000000+00:00"
                }
            }
        ]
    }
}

In this example, the ExperimentalAlgorithm feature is configured to be enabled for a specific time window. We specified the Microsoft.TimeWindow filter and set only the Start parameter to a concrete date.

By utilizing filtering in this way, we can control the availability of features based on various conditions. The library provides several pre-defined filters, and you can also create custom filters and configuration providers to suit your specific needs.

DEV Community: Krzysztof Begiedza

Infamous N+1 Query Problem with Entity Framework Core

Abstract

Introduction to the N+1 Query Problem

Why Does the N+1 Query Problem Occur in Entity Framework Core?

Strategies to Optimize Database Performance with Entity Framework Core

1. Eager Loading

2. Explicit Loading

3. Query Projection

4. (bonus) Disable Lazy Loading

Conclusion

Further reading

Secure Your Data with Entity Framework Core Encryption

Abstract

Implementation

Fluent configuration

Attribute-based configuration

Results

Conclusion

Further reading

Feature toggle management in .NET Core

Abstract

Setup

Basic usage

Usage in ASP.NET Core

Filters

Further reading