How to use it with EF Core bundle?

[Herve-M]

Hello!

I tried to migrated a project to this Mediator implementation, but I encounter an issue related to the build of EF Core bundle (and also during most ef design time flows) when the DbContext require IMediator while having a custom design-time setup.

One issue is related during the build of the bundle, who use BundleProjectGenerator.cs which csproj can't be customized neither be managed using preprocessor / symbol.

Another issue is related to most dotnet ef call, who fails as we can't have a dedicated setup flow, see below.

Context

• .NET 8
• EFCore 8.0.20
• Mediator 3.0.2

Example

internal sealed class ADbContext {
         public ADbContext (DbContextOptions<ADbContext > options, ILogger<ADbContext > logger, IMediator mediator)
            : base(options)
        {
            _logger = logger;
            _mediator = mediator;
        }
}

• While having a specific DI like:

internal sealed class Program
{
    // only used for EF Core design time resolving
    private static IHostBuilder CreateHostBuilder(string[] args)
    {
        IHostBuilder builder = Host.CreateDefaultBuilder(args);
        builder.ConfigureServices((hostContext, services) =>
        {
            services
                .AddMediator((MediatorOptions options) =>{ })
                 .UseInfrastructureLayer(hostContext.Configuration, hostContext.HostingEnvironment)
                      .WithDatabase() // call AddDbContext<>
                .Build();
        });
        return builder;
    }
   // only used for normal runs
   private static void Main(string[] args)
   {
     <many other stuff>
     builder.Services
            .AddMediator((MediatorOptions options) =>
            {
                options.Namespace = "myapp.Api.Server.Mediator";
                options.ServiceLifetime = ServiceLifetime.Scoped;
                options.GenerateTypesAsInternal = true;
                options.NotificationPublisherType = typeof(Mediator.ForeachAwaitPublisher);
                options.Assemblies =
                [
                    typeof(myapp.Domain.DependencyInjection).Assembly,
                    typeof(myapp.Application.DependencyInjection).Assembly,
                    typeof(myapp.Infrastructure.DependencyInjection).Assembly
                ];
                options.PipelineBehaviors =
                [
                    typeof(ValidationBehavior<,>),
                    typeof(InventoryTransactionBehavior<,>)
                ];
                options.StreamPipelineBehaviors = [];
            })
   }
}

while trying efcore cli run:

An error occurred while accessing the Microsoft.Extensions.Hosting services. Continuing without the application service provider. Error: Invalid configuration detected for Mediator. Generated code for 'Scoped' lifetime, but got 'Singleton' lifetime from options. This means that the source generator hasn't seen the 'AddMediator' method call during compilation. Make sure that the 'AddMediator' method is called from the project that references the Mediator.SourceGenerator package.

Then could try with setting up basic options:

    private static IHostBuilder CreateHostBuilder(string[] args)
    {
        IHostBuilder builder = Host.CreateDefaultBuilder(args);
        builder.ConfigureServices((hostContext, services) =>
        {
            services
                .AddMediator((MediatorOptions options) =>
                {
                    options.ServiceLifetime = ServiceLifetime.Scoped;
                    options.Assemblies = [];
                    options.PipelineBehaviors = [];
                    options.StreamPipelineBehaviors = [];
                })
                .UseInfrastructureLayer(hostContext.Configuration, hostContext.HostingEnvironment)
                      .WithDatabase() // call AddDbContext<>
                .Build();
        });
        return builder;
    }

but this can't be compiled due to this error: MediatorGenerator could not parse MediatorOptions-based configuration. Only compile-time constant values can be used in MediatorOptions configuration. Assemblies can only be configured once(MSG0007)

Is there anyway to setup an empty Mediator? (or did I miss something?)

Thanks,

[zyofeng]

You shouldn't inject mediator into dbcontext that will inevitably lead to circular reference.

[Herve-M]

You shouldn't inject mediator into dbcontext that will inevitably lead to circular reference.

What kind of circular reference?

It is pretty typical to have a events publisher in the DB Context to allow domain event publishing.

[zyofeng]

You shouldn't inject mediator into dbcontext that will inevitably lead to circular reference.

What kind of circular reference?

It is pretty typical to have a events publisher in the DB Context to allow domain event publishing.

DB context is infrastructure, domain event as the name suggests should be in your business logic layer (domain layer)

[Herve-M]

DB context is infrastructure, domain event as the name suggests should be in your business logic layer (domain layer)

I believe it is problem without a perfect solution, many tried ms.learn, even the eShop demo do it..
DDD books also state the same or hints about not being able to manage everything from within the domain layer.

Still, if you have any solid FOSS reference I could look into; always happy to learn more :-)

At the end, most of Mediator solution seems to work with this pattern, and with EF Core bundle..

Otherwise, I found a temporary hack, commenting the first options.Assemblies = [];:

private static IHostBuilder CreateHostBuilder(string[] args)
    {
        IHostBuilder builder = Host.CreateDefaultBuilder(args);
        builder.ConfigureServices((hostContext, services) =>
        {
            services
                .AddMediator((MediatorOptions options) =>
                {
                    options.ServiceLifetime = ServiceLifetime.Scoped;
                    // options.Assemblies = []; 
                    options.PipelineBehaviors = [];
                    options.StreamPipelineBehaviors = [];
                })
                .UseInfrastructureLayer(hostContext.Configuration, hostContext.HostingEnvironment)
                      .WithDatabase() // call AddDbContext<>
                .Build();
        });
        return builder;
    }

[zyofeng]

DB context is infrastructure, domain event as the name suggests should be in your business logic layer (domain layer)

I believe it is problem without a perfect solution, many tried ms.learn, even the eShop demo do it.. DDD books also state the same or hints about not being able to manage everything from within the domain layer.

Still, if you have any solid FOSS reference I could look into; always happy to learn more :-)

At the end, most of Mediator solution seems to work with this pattern, and with EF Core bundle..

Otherwise, I found a temporary hack, commenting the first options.Assemblies = [];:

private static IHostBuilder CreateHostBuilder(string[] args)
{
IHostBuilder builder = Host.CreateDefaultBuilder(args);
builder.ConfigureServices((hostContext, services) =>
{
services
.AddMediator((MediatorOptions options) =>
{
options.ServiceLifetime = ServiceLifetime.Scoped;
// options.Assemblies = [];
options.PipelineBehaviors = [];
options.StreamPipelineBehaviors = [];
})
.UseInfrastructureLayer(hostContext.Configuration, hostContext.HostingEnvironment)
.WithDatabase() // call AddDbContext<>
.Build();
});
return builder;
}

There are also more practical reasons not to do this. Your “events” model relies on EF Core change tracking, which won’t provide complete coverage — for example, operations like ExecuteUpdate bypass it entirely.

If you really want to go down this route. Then I would recommend looking into native sql change tracking (or the equivalent for your provider)
https://learn.microsoft.com/en-us/sql/relational-databases/track-changes/about-change-tracking-sql-server?view=sql-server-ver17

Create a background service to audit these changes and persist them.

[Herve-M]

Again, this is a solution architecture debate; most of last decade FOSS software and enterprise software do follow this pattern implying no easy solution, as you state, exist. (still didn´t share any repo. with a real working example or technical blog / books quote)

Also I can´t, by a hand click, refactor all my company code to change the flow and handling ways knowing they don´t use ExecuteUpdate / ExecuteDelete as it is very very recent. (.NET 10 / EF Core 10).

If no solution exists to make it work with EF Core bundle deployment and .NET DDD ways, then I believe we can close this topic.

[zyofeng]

Again, this is a solution architecture debate; most of last decade FOSS software and enterprise software do follow this pattern implying no easy solution, as you state, exist. (still didn´t share any repo. with a real working example or technical blog / books quote)

Also I can´t, by a hand click, refactor all my company code to change the flow and handling ways knowing they don´t use ExecuteUpdate / ExecuteDelete as it is very very recent. (.NET 10 / EF Core 10).

If no solution exists to make it work with EF Core bundle deployment and .NET DDD ways, then I believe we can close this topic.

ExecuteUpdate was introduced in EF Core 7 back in 2022 so not recent.
Architectural debate aside, a cleaner solution (at least in my view) would be to use ISaveChangesInterceptor.

You could then inject INotificationPublisher to publish events (one of which being audit), which feels more aligned with CQRS principles.