Finally wrapping up.

This is the seventh of a series about using Workflow Foundation to control your UI Logic in a WPF application. The full table of contents:

• Workflow as controller: Introducing <M,V,C> where M: ViewModel, V : WPF, C : WF
• Part II, starting the application, and the adapter
• Intermezzo: new sample application
• Part III, your first view
• Part IV, decoupling view from controller
• Part V, marshalling commands from WPF to WF, no content: was already done in Part IV !
• Part VI, Injecting a controller in a subview / workspace
• Part VII, IOC on the cheap: injecting and retrieving objects
• Part VIII, Broadcasting for all to see

Recap

In the first post, the complete solution was presented. I am presenting a solution to use workflow as the controller part in your MVC inspired WPF application. It is inspired on the thought that you do not need complex frameworks, because WPF already gives you great power (routed eventing, resources). So, no IOC is used, no event aggregator etcetera: it's taken care of by WPF and WF, a natural fit.
The solution is very decoupled and I feel it's a great advantage to be able to visual your control logic.
In the previous post we looked at injecting objects and retrieving.

Broadcasting

CAB (and other systems) uses an event aggregator to publish events. Subscribers (other controllers) can subscribe to a specific 'topic' using a string to identify it. This works well, but does mean yet another communication method is introduced.

Since every workflow/controller is added to the workflow runtime, we could easily ask for all the loaded workflows and send these a message. However, since all adapters subscribe to a weakevent manager to manage communication, I thought I'd stick to this pattern.

The BroadcastCommandMessage was created for the adapter to react on and check if it's controller is interested in it. If it is, the message is transformed to a command message and send to the controller.

I have not yet build an activity to do this.
The Bankteller sample has a CustomerQueueController. When it gets focus or loses focus, it wants to tell 'someone' (just someone who will listen) that it has a popular command to (un)register. The BanktellerLogic controller will use this information to put the command in a list and the view decides to make a menu item for it. You see, I do not believe that the CustomerQueueController should be able to decide that a menu is to be created out of it. He just wants to let the world know about a command.

        private void RegisterCommands(object sender, EventArgs e)

        {

            commandSvc.SendBroadcast(

                new BroadcastCommandMessage(this.WorkflowInstanceId, "RegisterPopularCommand",

                   CustomerQueueInteractions.AcceptNextCustomerFromQueue));

        }

        private void UnRegisterCommands(object sender, EventArgs e)

        {

            commandSvc.SendBroadcast(

                new BroadcastCommandMessage(this.WorkflowInstanceId, "UnRegisterPopularCommand",

                   CustomerQueueInteractions.AcceptNextCustomerFromQueue));

That concludes this series for now.

I hope you enjoyed it. I hope you take away the feeling that it is pretty easy to build a MVC system using WPF and WF and that the presented solution is about as decoupled as it gets.