After writing so much about my own MVC implementation for WPF, I'm happy to see the birth of Prism. This is what the site has to say about it:

"Prism" addresses the challenges around building complex enterprise WPF applications. As the complexity increases and the teams grow, the application becomes increasingly difficult to maintain. Using "Prism" enables designing a composite application that is composed of many discrete, loosely coupled modules. These modules can be developed, tested and deployed by separate teams.
It provides the following benefits:

• Provides complete support for WPF
• Dynamically composes user interface components
• Application modules are developed, tested and deployed by separate teams
• Allows incremental adoption
• Provides an integrated user experience

"Prism" is not a port of previous smart client offerings, instead it is a new deliverable that is optimzed for WPF. It aims to deliver a simplified approach that is more easily adoptable.

Very exciting!! Although I ofcourse will be disappointed if there is not a good way to integrate WF into it.

Just a random piece of code that I thought is handy: when you are experimenting with xml, you probably want to see the xml quickly and easily. For instance, when you are using the DataContractSerializer to serialize a type, you want to see how it looks. But it get's printed on one line!! That's not useful.

Use something like the following code:

            MemoryStream m = new MemoryStream();

            XmlTextWriter tw = new XmlTextWriter(m, Encoding.UTF8);

            tw.Formatting = Formatting.Indented;

            tw.Indentation = 4;

            tw.IndentChar = " ".ToCharArray()[0];

            s.WriteObject(tw, p);

            tw.Flush();

            m.Position = 0;

            StreamReader sr = new StreamReader(m);

            string strOutput = sr.ReadToEnd();

            Debug.WriteLine(strOutput);

<Person xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.datacontract.org/2004/07/DomainModel">

    <FirstName>Ruurd</FirstName>

    <LastName>Boeke</LastName>

    <Orders>

        <Order>

            <Amount>5</Amount>

            <ProductID>10</ProductID>

        </Order>

        <Order>

            <Amount>12</Amount>

            <ProductID>11</ProductID>

        </Order>

        <Order>

            <Amount>2</Amount>

            <ProductID>1</ProductID>

        </Order>

    </Orders>

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.

I'm a big reflection fan. However, reflection is slow and (for certain actions) requires full-trust. That's a big issue, since that means you can not use it in an unsigned xbap or whatever.

People are finding some cool ways to work around reflection where they can.

Ayende talks about the performance implications of creating objects here, and concludes that reflection might be slow, but you should ask yourself if you really care. If you do, he shows how to use dynamic methods to do the creation for you.

Roger Alsing takes it one step further, and uses Linq to build an expression tree to access private fields. Radical!! I love it. Read it here.
Also note his performance gains:

This approach is also much faster than Reflection.FieldInfo.
I made a little benchmark where I accessed the same field a million times.

The Reflection.FieldInfo approach took 6.2 seconds to complete.
The Compiled lambda approach took 0.013 seconds to complete.
That’s quit a big difference.

But keep in mind that actually compiling the expression is many times slower than reflection.