Yes, there is thread marshaling going on.Ideally I like to pump events that are just used to update the UI, and messages for BL. I do the marshaling on the event aggregator side.
On Wed, Oct 7, 2009 at 8:53 PM, Jason Meckley <[email protected]>wrote: > > Ok, so the piece I'm missing is the event aggregator which separates > the message consumption and background work from the UI. That said you > still need to manage the thread marshaling, correct? whether that's > done in the consumer, event aggregator or some other object linking > the two is a design decision. > > On Oct 7, 2:27 pm, Ayende Rahien <[email protected]> wrote: > > There are several ways of doing that.You can use OccationalConsumerOf<T>, > > but that is really for special cases. > > > > The way I would recommend to do it would be: > > > > a/ you publish a message to the bus from the UI > > b/ you have separate consumers that accept messages from the bus and > decide > > what needs to be done with it. > > As a good example, you aren't necessarily going to want to update the > same > > form that generated it. > > I usually do it in two modes, the consumer does whatever works needs to > be > > done on a background thread, then publish an event (locally in the > > application using event aggregator) that the forms can subscribe to. > > This create strong separation between UI actions and background actions, > > this is important for creating responsive application. > > > > On Wed, Oct 7, 2009 at 5:05 PM, Jason Meckley <[email protected] > >wrote: > > > > > > > > > The applications I develop are web-based. I have not had to directly > > > deal with threading at the GUI level with asp.net. I got around to > > > spiking a desktop app and passing work to background threads. nothing > > > fancy, just ThreadSlee(5000); return DateTime.Now.ToString("F"); > > > > > My first spike used ISynchronizeInvoke. I came to this solution by > > > getting the classic cross threading exception and following MSDN help > > > links. I can up with a solution, but didn't care for it to much. I > > > also remember reading that ISynchronizeInvoke is good for small > > > updates to a control or two, but it's not recommended for large UI > > > updates. I thought I remember Udi stating that in a podcast. > > > > > My second spike was taken from Jeremy's lastest MDSN article > > >http://msdn.microsoft.com/en-us/magazine/ee309512.aspxwhere he uses > > > the SynchronizationContext. I got this working and I must say I really > > > like it. > > > > > Somewhere in this forum's archive I have a lengthy thread about how to > > > use messaging. At first I thought is more of a middle tier framework > > > that would not be used by the UI. Oren said that messaging is a > > > perfect candidate for UI in that it pushes work to the background. At > > > least this is how I understood it. > > > > > However, spiking a WinForm+Message application never really clicked > > > for me. A consumer is transient and managed by the service bus. the > > > consumers are processed on background threads. A Form/UserControl > > > wouldn't implement ConsumerOf<T> directly because updates must happen > > > on the main thread. I don't see the Presenter implementing this either > > > as the presenter would normally reference a Form/UserControl > > > (abstracted through a IView). > > > > > Jeremy's example uses the ThreadPool.QueueUserWorkItem to push work to > > > background threads. I assume his example is still using a request/ > > > response model even though the work is delegated across threads. > > > > > Assuming the application is complex enough to warrant a messaging > > > architecture: > > > 1. Would a WinForms use both a messaging framework and something > > > similar to Jeremy's example of the AsynchronousExecutor (see link > > > above), or would the system use one of the two options? > > > 2. If the choice is exclusive and I choose messaging. how do I handle > > > consuming a message that would ultimately update the UI? > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
