Jason,
That is where EventBroker comes into place.
On Sat, Oct 2, 2010 at 1:53 PM, 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]<rhino-tools-dev%[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.
