membus v2 news

Membus 1.5.0 is a kind of V2 release in that it removed a number of things that had ben marked as obsolete and also provides users with a new feature.

IOC-Adapter

The dependency to the CommonServiceLocator package has been removed, you rather implement the IocAdapter-interface whose contract is straightforward:

public interface IocAdapter
{
    IEnumerable<object> GetAllInstances(Type desiredType);
}

Implement this interface, bridging e.g. to your DI-Container and finally use it when setting up MemBus:

_bus = BusSetup
    .StartWith<Conservative>()
    .Apply<IoCSupport>(s => s.SetAdapter(new MyAdapter()).SetHandlerInterface(typeof(GimmeMsg<>)))
    .Construct();

SetHandlerInterface is a new call that lets you provide an interface that your handler types implement. It expects an open generic type where the generic argument closes a single method defined on the interface that can accept one object and returns void (void Foo(T msg)).

Previously the interface that had to be implemented was fixed and provided by MemBus. The change means that there is a whole new category of classes that can be called by MemBus but do not take a direct dependency on it, since they implement an interface that you provide.

Flexible subscribing

The flexible subscription adapter has received an extension that allows you to subscribe methods that return either an object or as a special case an IEnumerable.

In both cases, MemBus will take the return value and either publish it back on the Bus again, or will enumerate the return value and publish every yielded object on the Bus.

Taking an example from the tests:

var bus = BusSetup
            .StartWith<Conservative>()
            .Apply<FlexibleSubscribeAdapter>(
            c => c.ByMethodName("Handle").PublishMethods("Route"))
            .Construct();

And a subscriber may look like this:

public class Controller {
    public View Route(Input msg) {
    return new View();
    }
}
...
bus.Subscribe(new Controller());

Now, when publishing a new Input instance, the Route-method will be called and the return value will subsequently be delivered to any subscribers of the View-Type.

This should open up a new set of scenarios where you have methods that publish a new message based on a different one. This scenario can now be implemented without taking a direct dependency to MemBus.