LiteBus and MediatR Differences

LiteBus and MediatR Differences

While both LiteBus and MediatR are in-process mediator libraries for .NET, they have different philosophies, architectures, and feature sets.

Philosophical Differences

• LiteBus: Designed with Domain-Driven Design (DDD) and Command Query Separation (CQS) as first-class citizens. It provides a rich, semantic type system and fine-grained control over the message handling pipeline, prioritizing flexibility and performance.
• MediatR: Describes itself as a "low-ambition library" focused on simple in-process messaging. It offers a more unified and simpler API, prioritizing ease of use and broad adoption.

Architectural Approaches

Aspect	LiteBus	MediatR
DI Integration	DI-agnostic runtime with adapters for specific containers (e.g., Microsoft DI, Autofac).	Tightly coupled with DI containers, with broad support for many.
Modularity	Highly modular (Commands, Queries, Events are separate). You can use only what you need.	More monolithic. The core concepts of Request/Notification are universal.
Handler Resolution	Uses a central MessageRegistry with cached descriptors to minimize runtime reflection.	Relies more on the DI container's IServiceProvider for handler resolution at runtime.

Feature Comparison

Feature	LiteBus	MediatR
Message Types	ICommand, IQuery, IStreamQuery, IEvent, and POCOs. Clear separation of concerns.	IRequest<T>, IStreamRequest<T>, INotification. More generic.
Pipeline Customization	Pre-handlers, Post-handlers, and Error handlers for each message type.	Pipeline Behaviors (IPipelineBehavior<,>) that wrap requests.
Event Concurrency	Advanced control: Sequential or Parallel execution for priority groups and handlers within groups.	A single NotificationPublisher.Strategy (Parallel, SyncContinueOnException, etc.).
Handler Filtering	Built-in support for filtering handlers via [HandlerTag] attributes and dynamic HandlerPredicate functions.	No built-in equivalent. Requires custom logic within a pipeline behavior.
Polymorphic Dispatch	Supported for pre/post/error handlers, allowing handlers for base types to process derived messages.	Not directly supported. A request for BaseType will not trigger a handler for DerivedType.
Durable Messaging	Built-in Command Inbox feature for guaranteed, deferred command execution.	No built-in equivalent. Requires external libraries.
Flow Control	AmbientExecutionContext.Abort() allows any handler to terminate the pipeline, optionally returning a result.	Not directly supported. A pipeline behavior can short-circuit by not calling next().

Use Case Considerations

Choose LiteBus when:

• You are building a system based on DDD/CQS principles and want a library that reflects that architecture.
• You need fine-grained control over the execution pipeline, especially for event concurrency.
• You require advanced features like handler filtering, polymorphic dispatch, or a durable command inbox out of the box.
• Minimizing runtime reflection and allocations is a primary concern.

Choose MediatR when:

• You prefer a simpler, more unified API and have less complex pipeline requirements.
• You are working on a project that already uses MediatR and benefits from its large ecosystem and community support.
• You need to support a DI container that LiteBus does not yet have an adapter for.