I'd opt for removing rather than replacing complexity. Apart from my testing scenario I can't think of another place where I would use instance subscriptions in production code. I can imagine situations like ASP.NET WebForms pages being instance subscribers but that just feels wrong to me (apart from the notion of using WebForms in the first place :) I'd much rather see RSB become lean and mean while still maintaining the out of the box simplicity that drew me to it in the first place. Perhaps your idea of the event aggregator could become a sample application, living in a new GitHub repo along with others showing examples of some advanced use cases. Or maybe instead of sample applications a "contrib" concept is introduced, though that is a slippery slop with version maintenance, etc… just some ideas….
Thanks, Matt On Sep 24, 2011, at 5:19 PM, Corey Kaylor wrote: > I might be able to do a hybrid of EventAggregator and regular subscription. > One that simplifies things internally and still provides hooks for instances. > The thing that I'm hung up on is I don't really think that it's very > important for publishing code to know the difference between instance > subscription and regular subscription. Thanks for your comments I'll keep > them in mind before ripping things apart. > > On a side note, I think I can do everything I've described with a new > registration mechanism while keeping all the existing stuff in place and > marking them as deprecated. If it works out it should provide people a little > bit of time to adapt. We'll see when I get a bit further. > > On Sat, Sep 24, 2011 at 2:47 PM, Matt Burton <[email protected]> wrote: > No - what you said makes sense. Doing what I'm doing now is not impossible > without instance subscription support - I can compensate by building other > components to stand in and deliver the same results. If removing them would > make RSB simpler then by all means go for it - I wasn't aware of how > complicated that feature is. At the end of the day it's saving me from having > to write extra code in my end to end tests, which is not a big deal. > > Thanks, > Matt > > On Sep 23, 2011, at 5:33 PM, Corey Kaylor wrote: > >> @Matt >> >> The common way that I handle sending messages to a particular instance is by >> having something that handles that concern by itself. One example that we >> have used is something similar to IEventAggregator in Caliburn. In our case >> we have hooks for when instances are created from the container and >> implements Handles<T> and is auto-subscribed with the event aggregator >> (Avoids the need for explicit subscription). >> >> slim example >> >> public void Consume(EventMessage message) >> { >> eventAggregator.Publish(message); >> } >> >> //in another class that might have typically implemented >> OccassionalConsumerOf<T> >> Handle(CustomerMoved message) >> { >> //do something >> } >> >> So the more specific question is... Would it be a big deal in the case of a >> published message on the bus to receive and not have any listeners i.e. >> already created handlers at the destination? >> >> There is a lot of working parts to make the instance subscriptions work with >> little payoff IMO. >> >> Does what I've said make sense, or am I missing something that this type of >> thing wouldn't work for in your case? >> >> On Fri, Sep 23, 2011 at 4:53 PM, Matt Burton <[email protected]> wrote: >> Sounds great, except for getting rid of OccasionalConsumerOf<T> - I >> use this a great deal in doing end to end tests - very handy. If >> there's a better way I'd love to know what it is. >> >> On Fri, Sep 23, 2011 at 1:14 PM, Corey Kaylor <[email protected]> wrote: >> > Thinking out loud here and looking to gauge reactions so don't take >> > anything >> > as concrete. >> > >> > After having worked with FubuMVC for some time now and seeing the power >> > that >> > customizable conventions bring, I've been thinking about how this might >> > simplify or change things with regard to the .NET service bus >> > implementations. In addition to thinking about conventions I've had some >> > ideas or nagging feelings for improvements. Let me know if you have others. >> > >> > Some ideas in no particular order. >> > >> > Changing heavily the way message endpoints are considered a consumer >> > through >> > convention, with a set of defaults that still leverages the existing >> > ConsumerOf<T> >> > Conventionally describe how sagas are initiated, finished, etc. >> > Bottles from Fubu to auto wireup endpoints for a given bottle - possibly in >> > its own appdomain >> > Conventionally determine routing? >> > Getting rid of OccasionalConsumerOf<T>, it's ugly, provides little value >> > and >> > can be handled with event aggregation inside your apps >> > Conventionally auto-subscribe >> > Chain of responsibility for consuming message pipline, aka BehaviorChains >> > in >> > Fubu >> > Message delivery expiration, if not able to send with timespan, discard (or >> > insert your convention here) >> > Endpoints that are considered volatile and will only retry send x times >> > (might only be possible with rhino queues at the moment) >> > Conventions for URI's to help with bottles scenario when using rhino queues >> > and requires more than one listening port >> > >> > An example might be at the host level saying for environment 'QA' port >> > starts with 55 >> > For the bottle level it might say the port ends with 24 >> > >> > Break up the transports into their own packages >> > In general the transports need to be broken up into different things that >> > handle smaller responsibility, separated to their own nuget packages >> > In the same vein the DefaultServiceBus could be broken down and separated >> > as >> > well, not the core IServiceBus interface, but rather the implementation >> > Make a common Message type used between transports >> > >> > -- >> > You received this message because you are subscribed to the Google Groups >> > "Rhino Tools Dev" group. >> > To post to this group, send email to [email protected]. >> > To unsubscribe from this group, send email to >> > [email protected]. >> > For more options, visit this group at >> > http://groups.google.com/group/rhino-tools-dev?hl=en. >> > >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Rhino Tools Dev" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rhino-tools-dev?hl=en. >> >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Rhino Tools Dev" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rhino-tools-dev?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Rhino Tools Dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rhino-tools-dev?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Rhino Tools Dev" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rhino-tools-dev?hl=en. -- You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rhino-tools-dev?hl=en.
