Can generated code work through multiple projects

[Duranom]

Was just wondering, I have a situation where the layers define their own dependencies instead of everything fully on the outer layer.
For example:

• Application layer registers everything it needs
• Api layer registers what it needs, and things from Application layer are done by calling an extensions exposed by Application layer to do its work.

This is done to allow also several integration and system tests to be configured and register the services and avoid having (near) duplicates of registrations on several places.
Currently noticing erros due to following two issues:

• A mediator is generated for every project performing AddMediator(...) and the last one performing wins.
• Everything is generated to be added through with Add

I think I cannot work around the issues without some changes to the library, so was wondering if the library could evolve so that not a Mediator class is generated but supplied by the library and that it expects to receive something like an IEnumerable<IMedatiorProcessor>.
So a brain fart idea like:

• A predefined library, or generated if desired, Mediator is made that receive an IEnumerable<IMedatiorProcessor> and message gets forwarded to the generated MediatorProcessor.
  • Storing the IMediatorProcessors could be stored in a FrozenDictionary or other things
• All current logic of Send and such is moved to a generated MediatorProcessor which is then registered with TryAdd.

Could also perhaps have

• Methods generated on the MediatorProcessor, like the Send methods, are also generated as extensions for Mediator which do an immediate forward to the type. Would mean the Mediator would have to expose the registered handlers, but also gives the capability to keep the link between the message and handler with going to implementation.

This would allow the following where it currently causes issues:
Api layer - only needs to define what it needs itself enriched

static void AddDependencies()
{
    ...
    services.AddMediator(options =>
    {
        // options.Namespace = "SimpleConsole.Mediator"; // only needed if want generated code in different namespace, but otherwise could be determined from project namespace(?) and should not conflict with any other generating additions
        options.Assemblies = [typeof(ApiServiceCollectionExtensions)]; 
        options.PipelineBehaviors = [typeof(ApiPipelineBehavior)];
        options.StreamPipelineBehaviors =  [typeof(ApiStreamPipelineBehavior)];
    });
    AddApplicationDependencies(services); // order should not matter
}

Application

static void AddApplicationDependencies(this IServiceCollection services)
{
    services.AddMediator(options =>
    {
        options.Assemblies = [typeof(ApplicationServiceCollectionExtensions)]; 
        options.PipelineBehaviors = [typeof(ApplicationPipelineBehavior), typeof(LoggingPipelineBehavior)];
        options.StreamPipelineBehaviors =  [typeof(ApplicationStreamPipelineBehavior), typeof(LoggingStreamPipelineBehavior)];
    });
}

Should the API decide to put additional assemblies, like that of the application, than the AddMediator in AddApplication will not add everything for a second time due to TryAdd usage.

[martinothamar]

This is atleast slightly similar to alternatives that have been discussed in similar threads previously, going away from 1 global generated implementation to several, or at the very least that codegen is scoped to individual projects, and then in some way dynamically routing the the relevant module/processor..

I have an issue here that references some of these discussions: #97

There is some fundamental difficulty here with trying to reconcile compile time decisions and runtime branching. Like there is some AddMediator call that has to "win", in that it has its' IMediator implementation being the thing that is resolved through IMediator in IServiceProvider. People have generally brought this topic on in the context of "Modular Monolith" type architecture where you typically want to be able to run these modules in different contexts.

I'm assuming there is still 1 global IServiceProvider in your scenario?
So then this 1 Mediator implementation that get's resolved from IServiceProvider has to be able to resolve each message to an individual IMessageProcessor? Then you have the concept of notifications where I think people (rightfully) have the expectation that these are broadcasted across different modules/projects. One can technically also put requests in shared libraries and have handlers multiple places, and I guess that would also have to be a runtime validation thing. This is a very non-trivial change that would really push on the stated goals (and therefore constraints) of the project currently, so would need to spend some time prototyping, testing, verifying before committing to anything.

We have some sample larger appllication samples that do span multiple projects. During v3 we added GenerateTypesAsInternal and Assemblies to support some additional architectures, for example the Blazor one which has Mediator running on both client and serverside (and the server references the client). So for your specific scenario I think the best way to start is to examine the existing samples to see if they solve any problems that you have in your architecture.

Finally, to get any further on this topic, I think we would need a PR with a simplified sample that has the issues people commonly see, and use that to drive the discussion forward. Until now there has been a lot of discussion and very little code, which perhaps leaves a little too much discussion to the imagination 😄

[Duranom]

Will look at the discussions.

Though scenario where I encountered is not a monolith and it does have one IServiceProvider but the biggest reason is it is enforced to follow a policy where each layer component must register its own services.
This due several components on some layers, infra, depends on a external dependency that require integration tests to spin up a container or other special requirements. And yes, the layer with business logic is partially carved to separate libraries for the subdomains.

Doubt commonly, as due policy and the integration tests causing it, but it was a thing that was suddenly turning integration tests to red after switching from MediatR to your package.
Not sure if that is something would want as a sample, but could otherwise create a very dumbed sample use-case of it regarding sometime.