These are chat archives for christopherread/Obvs

23rd
Feb 2016
Drew Marsh
@drub0y
Feb 23 2016 19:03
hey @inter8ection, as I put together samples for people I'm noticing a "deficiency" in the API that I think is a result of the older Obvs 1.x style where IMessage was the base of everything
specifically, ServiceEndpoint still takes a Type serviceType parameter and, considering it's generic with the TMessage that already represents my base message type, that seems awfully redundant
but, that's kind of an internal detail, the real pain is felt when people are using the configuration API and have to do something like this:
ServiceBus<MyMessage, MyCommand, MyEvent, MyRequest, MyResponse>.Configure()
                .WithAzureServiceBusEndpoint<MyMessage, MyMessage, MyCommand, MyEvent, MyRequest, MyResponse>()
there's a redundant MyMessage there
you have this in your implementations too (e.g. netmsmq) and it's like super verbose/redundant
Drew Marsh
@drub0y
Feb 23 2016 19:08

really should just be able to do this

ServiceBus<MyMessage, MyCommand, MyEvent, MyRequest, MyResponse>.Configure()
                .WithAzureServiceBusEndpoint(...)

and have it infer the types from the ServiceBus<>... so I think I'm going to add an extension method overload to do that in my version, but I'm passing it on so you can maybe make the same overloads for your version to make things easier for your consumers as well

Drew Marsh
@drub0y
Feb 23 2016 19:14

so basically I'm offering a new overload of my WithAzureServiceBusEndpoint that assumes the TMessage is also the TServiceMessage:

public static ICanAddAzureServiceBusServiceName<TMessage, TCommand, TEvent, TRequest, TResponse> WithAzureServiceBusEndpoint<TMessage, TCommand, TEvent, TRequest, TResponse>(this ICanAddEndpoint<TMessage, TCommand, TEvent, TRequest, TResponse> canAddEndpoint)
            where TMessage : class
            where TCommand : class, TMessage
            where TEvent : class, TMessage
            where TRequest : class, TMessage
            where TResponse : class, TMessage
        {
            return canAddEndpoint.WithAzureServiceBusEndpoint<TMessage, TMessage, TCommand, TEvent, TRequest, TResponse>();
        }

and now my end users can just do

ServiceBus<MyMessage, MyCommand, MyEvent, MyRequest, MyResponse>.Configure()
                .WithAzureServiceBusEndpoint()

because all of the type params will be inferred from the this ICanAddEndpoint<> type

Drew Marsh
@drub0y
Feb 23 2016 19:35
done and pushed with my 0.9.0-beta release of Obvs.AzureServiceBus
now, I have something else I've been working on that you might want to take look at which is that I've written a framework for message dispatching based off of Obvs called Obvs.MessageDispatcher
and a companion integration library that pairs it with Autofac called Obvs.MessageDispatcher.Autofac
Drew Marsh
@drub0y
Feb 23 2016 19:47
hopefully the READMEs will explain everything, but love to have some feedback on it... I found this helped my teams move way faster because they just think in terms of writing IMessageHandler<TMessage> components that handle messages and don't have to worry about all the routing type problems at the Rx level