Yes Corey, that is what I have done in the end. My current implementation is using an IMessageModule implementation to publish messages via my implementation of EventAggregator.
It works well enough. On Oct 3, 1:53 am, Corey Kaylor <[email protected]> wrote: > Use something like an eventaggregator and have your presenter implement > something like IHandler<T> that is only subscribed when resolved. Then just > forward the message to the aggregator. This gives the benefit of > OcassionalConsumer without the downsides. > > Sent from my iPhone > > On Oct 2, 2010, at 7:53 AM, Jason Meckley <[email protected]> wrote: > > > > > I presenter would send the message, from the client to the server. > > when the client receives a response from the server another consumer > > would handle that. that consumer may depend on the presenter to > > process the message. I would model it like this > > > class Presenter > > { > > public IService Bus {get;set;} > > > public void GetData() > > { > > //expects the server to return Response object > > bus.Send(new Message()); > > } > > > public void Display(Response response) > > { > > ... > > } > > } > > > //UserInterfaceConsumer from Ayende's example above > > public class ResponseConsumer : UserInterfaceConsumer<Response> > > { > > public Presenter {get;set;} > > > public abstract void ExecuteInUIThread(Response msg) > > { > > presenter.Display(msg); > > } > > } > > > I haven't done much with rich clients. but this would be my approach. > > The only thing left to consider is injecting the presenter. If > > presenters are transient (which I assume they are) how do you get the > > same instance of the presenter, into the consumer (same presenter to > > send and receive)? or can the presenter be a new instance, but the > > View is the same instance? That is where I'm stuck. > > > On Oct 1, 6:11 pm, John J <[email protected]> wrote: > >> I guess the reason I was going for an attribute-based implementation > >> instead of class inheritance was to cater for the situation where > >> multiple messages are consumed by the one class. In particular, I am > >> thinking of my MVP design, where the presenter would be sending and > >> consuming messages: > > >> class MyPresenter : Presenter<IMyView>, > >> OccasionalConsumerOf<MessageA>, OccasionalConsumerOf<MessageB> > >> { > >> public IServiceBus Bus { get; set; } > > >> public override void Init() { > >> Disposables.Add(Bus.AddInstanceSubscription(this)); > >> } > > >> [UIThread] > >> public void Consume(MessageA message) { > >> // ... do something here that affects the view, and should be on > >> the UIThread > >> } > > >> public void Consume(MessageB message) { > >> // ... do something here that does not affect the view > >> } > >> } > > >> I read somewhere on this forum that OccasionalConsumerOf was > >> discouraged (even though it is in the sample starbucks application). I > >> had a quick look and did not easily find it again, so I can't remember > >> why it was discouraged. What I did find, however, was that if you use > >> the MSMQ subscription storage, every time you subscribe and > >> unsubscribe an instance, you add another message to the subscriber > >> queue. If you have a lot of client programs running through a lot of > >> presenters, that subscription queue is going to get pretty big pretty > >> quickly. > > >> Are there any other reasons why I should stay away from > >> OccasionalConsumerOf<T>? > > >> I have also realised that my goal to have my presenters doing work on > >> the UI thread could be implemented another way, for example using the > >> Castle Synchronize facility. I might be better trying to get that > >> going properly with my application, rather than trying to force rhino > >> esb to know about UI threads. > > >> Has anyone else tried the synchronize facility with rhino esb? > > >> On Sep 30, 9:45 pm, Ayende Rahien <[email protected]> wrote: > > >>> public abstact class UserInterfaceConsumer<T> : ConsumerOf<T> > >>> { > >>> public static SyncronizationContext SyncronizationContext { get;set; |} > >>> public void Consume<T>(T msg) > >>> { > >>> SyncronizationContext.Send( delegate { ExecuteInUIThread(msg); }, > >>> null); > >>> } > > >>> public abstract void ExecuteInUIThread(T msg) > >>> { > >>> } > > >>> } > > > -- > > 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 > > athttp://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.
