Skybeam 0.2.0

Skybeam

Mediator-like service decoration without an actual mediator:

• Improved code readability with explicit class dependencies and source generation. There is no IMediator or a service locator.
• Supports decorators / middlewares / behaviors.
• Built for modern ASP.NET Core on top of Microsoft.Extensions.DependencyInjection.
• Better performance: pipelines are source-generated. There is no reflection or dictionary lookups on handlers execution path.
• Handler and behavior contracts are intentionally made similar to MediatR.
• By now, it's more of a proof-of-concept project.

If the only feature you need from MediatR is decoration, consider opting out. CQRS handler decoration (in a form of middlewares, pipelines, behaviors etc.) can be implemented in many other ways:

• Reflection + DI: the classic, robust, and most flexible approach - less explicit, not the fastest, and not AOT-friendly.
• IL weaving: PostSharp etc.
• Source generation + DI: Skybeam (this project).

How to start

Reference Skybeam package directly in every project containing handlers. Preferably use Directory.Build.props in your solution to ensure that.

Use Skybeam.IRequestHandler for the handlers:

public class FirstHandler : IRequestHandler<Alpha, Omega>
{
    public Task<Omega> HandleAsync(Alpha input, CancellationToken ct = default) {}
}

Use Skybeam.IPipelineBehavior for the behaviors:

public class FirstBehavior<TRequest, TResponse> : IPipelineBehavior<TRequest, TResponse>
{
    public Task<TResponse> HandleAsync(
        TRequest request, 
        RequestHandlerDelegate<TResponse> next, 
        CancellationToken ct = default) {}
}

Build the project to trigger source generation. Then register the generated pipelines:

services.AddSkybeam()
    .AddBehavior(typeof(FirstBehavior<,>))
    .AddBehavior(typeof(SecondBehavior<,>), ServiceLifetime.Singleton);

Remarks

• Handler registration is optional and can be used to control handler lifetime.
• Handler's lifetime is preserved if there is a IRequestHandler<T1, T2> registration before AddSkybeam call. Otherwise, it defaults to Transient.
• Behaviors are invoked in registration order.
• Behavior's lifetime is either specified in AddBehavioror defaults to Transient.

Some explanation

What is PipelineRegistry

Skybeam.YourProject.PipelineRegistry type is the access point to the source code generated by Skybeam. By navigating to the registry's definition, you can inspect all discovered handlers and how they're processed. Each handler has a respectful source-generated pipeline that replaces a handler's registration in DI:

services.ReplaceWithPipeline<
	IRequestHandler<Alpha, Omega>, 
	FirstHandler, 
	FirstHandlerPipeline>();

Multiple registry types

In real-world applications, handlers are often located in multiple separated projects (e.g., YourProject.BusinessLayer). This leads to several PipelineRegistry types generated due to how C# source generators work. To use only one registry, just specify it in AddSkybeam<T> call, which means only the handlers from this respectful registry will be decorated (you probably don't want that). To process all handlers, stay on non-generic AddSkybeam version: this method runs a reflection-based assembly scan to find all available registries. What can be further limited by setting ScanAssemblies option:

services.AddSkybeam<Skybeam.YourProject42.PipelineRegistry>();

// or
services.AddSkybeam(options =>
{
    options.ScanAssemblies = [typeof(DummyRegistry).Assembly];
});

Known limitations

• Currently supports only Microsoft.Extensions.DependencyInjection.
• Full AOT compatibility is not guaranteed yet.