Hi there!

I've recently started using a Nancy-esque library called Carter for Web API's instead of plain MVC, and I've hit a bit of a snag when using the bus from its modules. I'm not quite sure what the problem is, but the symptom is that the IDepenencyScope that the bus uses to start a new scope to resolve handlers is already disposed. I saw there was another issue around multiple handlers, but this one has just a single event and single handler.

I've created a working reproduction here https://github.com/gkinsman/MicroBusRepro.

Any thoughts would be welcome!

Events are usually subscribed to by multiple parties all interested in the one event. Events in MicroBus should support registering multiple handlers to them.

When using a Saga to kick off a command that will, in turn, generate an event to finish the saga, the generated event happens twice.

I'm not sure if that's because I'm "doing it wrong", or if there's a problem in the way the sagas are run.

I created a fork (see reference below) with a unit test (CompleteCommandingSagaTests.cs) to demonstrate the problem. Specifically, in the TestCommandingSaga.cs file, I have two classes - the Saga and the Command Handler. I expect the SagaEndingEvent only once, but it happens twice.

public class TestCommandingSaga : ISaga,
        ISagaStartedBy<SagaStartingAEvent>,
        IEventHandler<SagaEndingEvent>
    {
        public Guid Id { get; protected set; }
        public bool IsCompleted { get; protected set; }
        public static string Status { get; protected set; }

        private readonly IMicroBus Bus;
        public TestCommandingSaga(IMicroBus bus)
        {
            Bus = bus;
        }

        public async Task Handle(SagaStartingAEvent @event)
        {
            Id = @event.CorrelationId;
            Status = "Started, ";
            await Bus.SendAsync(new EndSaga { CorrelationId = Id });
        }

        public async Task Handle(SagaEndingEvent @event)
        {
            Status += "Finished.";
            IsCompleted = true;
        }
    }

    public class EndSagaCommandHandler : ICommandHandler<EndSaga>
    {
        private readonly IMicroBus Bus;
        public EndSagaCommandHandler(IMicroBus bus)
        {
            Bus = bus;
        }

        public Task Handle(EndSaga command)
        {
            Bus.PublishAsync(new SagaEndingEvent { CorrelationId = command.CorrelationId });
            return Task.CompletedTask;
        }
    }

Thoughts?

Hello,
first of not sure if this expected or not, I was moving across some CommandHandlers from another lib to MicroBus.

I intially had code such as this:

public interface IFooHandler : Enexure.MicroBus.ICommandHandler<FooCommand> {} 
public class Foo : IFooHandler {}

which gives the InvalidDuplicateRegistrationsException in the Autofac buildup for FooCommand.
There is only one class that implements the interface.

Changing to below fixes it:

public class Foo : Enexure.MicroBus.ICommandHandler<FooCommand> {}

Should the duplicate registrationError occur for this?

[email protected] has dependency to [email protected] which has vulnerability: LINK. Please update it to newer version if possible.

Update:
It's because .net standard that is used in this project references [email protected]. At the end of the day, application will use System.Text.RegularExpressions provided by .net SDK installed on the machine. It means that as long as SDK is in newest version there should be no problem, but it would be nice to have this package targeted for the newest LTS .net.

The library has IQuery<in TQuery, out TResult> interface.

There should be a similar version for commands that will allow for a result object ICommand<in TCommand, out TResult>. It should work in similar way as query does.

Purists will argue that commands must not return anything, but there are several good reasons for that:

• it reduces complexity and simplifies your application, especially when you're not using eventual consistency nor client-generated ids.
• This information will dramatically improve the user experience of your system, because you don’t have to poll an external source for command execution result, you have it right away. It becomes trivial to validate commands, and to return error messages.
• If you want to refresh the displayed data, you can use the aggregate’s new version to determine whether the view model reflects the executed command or not. No more displaying stale data.

Example use cases:

• Return information if record was deleted or not: public class DeleteFoo : ICommand<DeleteFoo, bool>
• Return number of affected rows: public class DeleteFoos : ICommand<DeleteFoos, int>
• Return new version number of your aggredate public class ChangeFoo : ICommand<ChangeFoo, int>
• Return object containing more-verbose result of the operation: public class PerformComplexOperation: ICommand<PerformComplexOperation, OperationResult>
• Return ID of created object in relational databases: public class CreateFoo: ICommand<CreateFoo, int>

See also: https://vladikk.com/2017/03/20/tackling-complexity-in-cqrs/

Hi Daniel,

I have looked at mediatr and this and found your implementation "attractive".
I would like to have an implementation for AspNetCore IoC.

Made an attempt but run into trubble :)

Best,

Hi, are you able to publish a new version of Enexure.MicroBus.Autofac for version 3.6.2 with the latest fixes for .net core 2.1 as well ?

Thanks

When using MicroBus.Autofac dependencies that are registered with InstancePerLifetimeScope() should be scoped to a message passing through the bus.

See http://docs.autofac.org/en/latest/faq/per-request-scope.html

I'm leaning towards Microbus over Mediatr.
The problem is we prefer to use StructureMap and I can't find what I need to make it work with it as all your tutorials speak to Autofac.

I'd appreciate any help getting this work.

Hi Daniel,

I have just taken a look at mediatr and this. Good work btw, your implementation performs really well. It would be useful to be able to define a global handler that is restrictable to specific types, similar to mediatr implementation in their PipelineBehavior.

IPipelineBehavior<ChangeUserAddressData, UserAddressData>), typeof(LoggingBehavior<ChangeUserAddressData, UserAddressData>));

Additionally it would be useful to be able to add an interface on the message handlers, omit or include list of GlobalHandlers that could be passed when registering the handler.

Best,

Ian.

In ReflectionExtensions.GetTaskResult typeInfo.GetDeclaredProperty("Result") is returning null causing an exception. This is throwing in the unit tests when targeting netcoreapp2.1 as well.

System.NullReferenceException : Object reference not set to an instance of an object.
   at Enexure.MicroBus.ReflectionExtensions.GetTaskResult(Task task) in C:\Users\andrewm\Downloads\Enexure.MicroBus-master\Enexure.MicroBus-master\src\Enexure.MicroBus\Implementation\ReflectionExtensions.cs:line 57
   at Enexure.MicroBus.PipelineRunBuilder.RunHandlers(IReadOnlyCollection`1 leafHandlerTypes, Object message, CancellationToken cancellation) in C:\Users\andrewm\Downloads\Enexure.MicroBus-master\Enexure.MicroBus-master\src\Enexure.MicroBus\Implementation\PipelineRunBuilder.cs:line 128
   at Enexure.MicroBus.PipelineRunBuilder.<>c__DisplayClass7_0.<<BuildNextHandler>b__0>d.MoveNext() in C:\Users\andrewm\Downloads\Enexure.MicroBus-master\Enexure.MicroBus-master\src\Enexure.MicroBus\Implementation\PipelineRunBuilder.cs:line 84
--- End of stack trace from previous location where exception was thrown ---
   at Enexure.MicroBus.MicroBus.RunPipelineAsync(Object message, CancellationToken cancellation) in C:\Users\andrewm\Downloads\Enexure.MicroBus-master\Enexure.MicroBus-master\src\Enexure.MicroBus\Implementation\MicroBus.cs:line 63
   at Enexure.MicroBus.Autofac.Tests.ScopesAndDisposeTests.InTheDefaultAutofacScopeCommandHandlersShouldFinishBeforeTheScopeIsDisposed() in C:\Users\andrewm\Downloads\Enexure.MicroBus-master\Enexure.MicroBus-master\src\Enexure.MicroBus.Autofac.Tests\ScopesAndDisposeTests.cs:line 101
--- End of stack trace from previous location where exception was thrown ---

The update for infrastructure contracts has increase the .net dependency from 4.5 to 4.5.1. Can the support for 4.5 please be re-added, at least to the contracts?

When I try to download the solution from nuget the assembly is not signed and therefore I get an error when compiling.

Currently sending a message that has not been registered will throw an exception. Instead make this configurable so that this can be handled and a custom action taken instead.

Enable Nullable types compiler option allowing code that uses MicroBus to benefit from better static analysis regarding null checks.

This also has the side affect of highlighting any null related issues within MicroBus itself.

Hey there,

It looks like you're throwing an exception if there's no result type on returned tasks, except that Task.Completed task has no result, and thus fails :). Perhaps we could allow the use of CompletedTask and just treat it as a void return?

Cheers,
George

Maybe add an extension to the BusBuilder to create a bus simply from there? That way it's easy to work with MicroBus in LINQPad, and etc.

Thanks!

The code below causes an ObjectDisposedException to be thrown with the message "Instances cannot be resolved and nested lifetimes cannot be created from this LifetimeScope as it has already been disposed."

async Task Main()
{
	var builder = new Autofac.ContainerBuilder();
	var busBuilder = new BusBuilder()
		.RegisterHandlers(this.GetType().Assembly);

	builder.RegisterMicroBus(busBuilder);
	using (var container = builder.Build())
	{
		var bus = container.Resolve<IMicroBus>();
		await bus.SendAsync(new TestCommand());
	}
}

class TestCommand : ICommand { }
class TestEvent : IEvent { }
class TestNestedCommand : ICommand { }

class TestCommandHandler : ICommandHandler<TestCommand>
{
	private readonly IMicroBus _bus;
	public TestCommandHandler(IMicroBus bus)
	{
		_bus = bus;
	}
	public async Task Handle(TestCommand command)
	{
		Console.WriteLine("Test command handler");
		await _bus.PublishAsync(new TestEvent());
	}
}

class TestEventHandler : IEventHandler<TestEvent>
{
	private readonly IMicroBus _bus;
	public TestEventHandler(IMicroBus bus)
	{
		_bus = bus;
	}
	public async Task Handle(TestEvent @event)
	{
		Console.WriteLine("Test event handler");
		await _bus.SendAsync(new TestNestedCommand());
	}
}

class TestOtherEventHandler : IEventHandler<TestEvent>
{
	private readonly IMicroBus _bus;
	public TestOtherEventHandler(IMicroBus bus)
	{
		_bus = bus;
	}
	public async Task Handle(TestEvent @event)
	{
		await Task.CompletedTask;
		Console.WriteLine("Test other event handler");
	}
}

class TestNestedCommandHandler : ICommandHandler<TestNestedCommand>
{
	private readonly IMicroBus _bus;
	public TestNestedCommandHandler(IMicroBus bus)
	{
		_bus = bus;
	}
	public async Task Handle(TestNestedCommand command)
	{
		await Task.CompletedTask;
		Console.WriteLine("Test nested command handler");
	}
}

Registering a handler currently requires you to define a class which implements a handler interface such as ICommandHandler. I would also be useful to register functions and delegates as handlers as well.

var busBuilder = new BusBuilder()
        .RegisterHandler<MessageReceived>(event => { ... });

Add a MicroBus.Ninject package for bindings to Ninject.

Is there any built-in retry logic?
I am looking for simple mediators where I can publish an event and have multiple subscribers consuming it, and MicroBus seems like a perfect fit for it, so thank you.

But I am exploring scenarios where it would be good to have some kind of retry logic. For example if I have one event A that is supposed to arrive after another event B but for whatever reason in microbus the event B is placed before event A, therefore I could throw an exception when handling event B (because A hasn't been processed yet) and hope to have some retry logic built in with MicroBus so that in the next attempts it eventually succeeds.

If this is a scenario where I could use MicroBus, could you please point me to the right place to explore it? Thanks

Hi Daniel,

I have recently been testing both Microbus and Mediatr in a UWP app, I have only managed to get yours to work...

The UWP app utilizes MvvmLight

It would be good to add LightInject, I have it working with Autofac ok.

Ian

First of all, thanks for the project! I like it.

Request though: I'm figuring it out myself and it's well designed -- but more examples would be nice.

Currently you have to register each message and handler explicitly. Sometimes it would be nice to auto discover and register handlers in an assembly. Syntax would look something like this.

handlerRegister.RegisterTypes(
    type => type.FullName.Contains("NameSpaceToInclude"),
    somePipeline, 
    someAssembly)

Hi.

I'd like to run something like:

            _myPreinitializedService=new UsefulCommandHandler("my default value");
            _myPreinitializedService.DoLongInitialization().Wait();

            // AUTOFAC REGISTRATIONS
            _containerBuilder = new ContainerBuilder();
            _containerBuilder.RegisterInstance(_myPreinitializedService).As<UsefulCommandHandler>();

            // BUS
            var busBuilder = new BusBuilder()
                .RegisterCommandHandler<UsefulCommand, UsefulCommandHandler>();

            var container = _containerBuilder.RegisterMicroBus(busBuilder).Build();

            _bus = container.Resolve<IMicroBus>();

but, since UsefulCommandHandler has only a non default ctor (taking a string MyParameter parameter) whenever I call

_bus.SendAsync(new UsefulCommand());

...I get a:

None of the constructors found with 'Autofac.Core.Activators.Reflection.DefaultConstructorFinder' on type 'UsefulCommandHandler' can be invoked with the available services and parameters:
Cannot resolve parameter 'System.String MyParameter' of constructor 'Void .ctor(System.String)'.

Same type resolution before calling:

            // BUS
            var busBuilder = new BusBuilder()
                .RegisterCommandHandler<PingParadoxHostCommand, ParadoxServiceProvider>();

            var container = _containerBuilder.RegisterMicroBus(busBuilder).Build();

            _bus = container.Resolve<IMicroBus>();

...works as expected (i.e. autofac correctly resolves type with my preinitialized instance).

What is the proper way to do it?

Thanks!