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 at
http://groups.google.com/group/rhino-tools-dev?hl=en.
