so in a sense passing the message from the service bus, to a UI event bus. that makes sense. when a presenter is resolved it's registered to the event aggregator. you could also put the sync. context in the event aggregator. it seems like it would make more sense there.
On Oct 2, 11: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.
