Merq.DependencyInjection 2.0.0-rc.6

var builder = WebApplication.CreateBuilder(args);
...
builder.Services.AddMessageBus();

All command handlers and event producers need to be registered with the services collection as usual, using the main interface for the component, such as ICommandHandler<T> and IObservable<TEvent>.

NOTE: Merq makes no assumptions about the lifetime of the registered components, so it's up to the consumer to register them with the desired lifetime.

To drastically simplify registration of handlers and producers, we recommend the Devlooped.Extensions.DependencyInjection.Attributed. package, which provides a simple attribute-based mechanism for automatically emitting at compile-time the required service registrations for all types marked with the provided [Service] attribute, which also allows setting the component lifetime, such as [Service(ServiceLifetime.Transient)] (default lifetime is ServiceLifetime.Singleton for this source generator-based package).

This allows to simply mark all command handlers and event producers as [Service] and then register them all with a single line of code:

builder.Services.AddServices();

Telemetry and Monitoring

The core implementation of the IMessageBus is instrumented with ActivitySource and Metric, providing out of the box support for Open Telemetry-based monitoring, as well as via dotnet trace and dotnet counters.

To export telemetry using Open Telemetry, for example:

using var tracer = Sdk
    .CreateTracerProviderBuilder()
    .SetResourceBuilder(ResourceBuilder.CreateDefault().AddService("ConsoleApp"))
    .AddSource(source.Name)
    .AddSource("Merq")
    .AddConsoleExporter()
    .AddZipkinExporter()
    .AddAzureMonitorTraceExporter(o => o.ConnectionString = config["AppInsights"])
    .Build();

Collecting traces via dotnet-trace:

dotnet trace collect --name [PROCESS_NAME] --providers="Microsoft-Diagnostics-DiagnosticSource:::FilterAndPayloadSpecs=[AS]Merq,System.Diagnostics.Metrics:::Metrics=Merq"

Monitoring metrics via dotnet-counters:

dotnet counters monitor --process-id [PROCESS_ID] --counters Merq

Example rendering from the included sample console app:

Duck Typing Support

Being able to loosely couple both events (and their consumers) and command execution (from their command handler implementations) is a key feature of Merq. To take this decoupling to the extreme, Merq allows a similar capability as allowed by the TypeScript/JavaScript in VSCode: you can just copy/paste an event/command definition as source into your assembly, and perform the regular operations with it (like Observe an event and Execute a command), in a "duck typing" manner.

As long as the types' full name match, the conversion will happen automatically. Since this functionality isn't required in many scenarios, and since there are a myriad ways to implement such an object mapping functionality, the Merq.Core package only provides the hooks to enable this, but does not provide any built-in implementation for it. In other words, no duck typing is performed by default.

The Merq.AutoMapper package provides one such implementation, based on the excelent AutoMapper library. It can be registered with the DI container as follows:

builder.Services.AddMessageBus<AutoMapperMessageBus>();
// register all services, including handlers and producers
builder.Services.AddServices();

Dogfooding

We also produce CI packages from branches and pull requests so you can dogfood builds as quickly as they are produced.

The CI feed is https://pkg.kzu.dev/index.json.

The versioning scheme for packages is:

• PR builds: 42.42.42-pr[NUMBER]
• Branch builds: 42.42.42-[BRANCH].[COMMITS]

Sponsors

Learn more about GitHub Sponsors

For usage and authoring of commands and events, see Merq readme.

Sponsors

Learn more about GitHub Sponsors