I had a good question in the comments of Part 2 of my series on WCF RIA Services that I thought I would answer here so more could find the information.

To paraphrase the question: “How can I retrieve a set of entities into my client and process them when the retrieval is complete?

I didn’t go into detail on the latter part of this in the article because of space limitations. But basically the answer is that you can be notified of the completion of any async operation (Load and SubmitChanges primarily) that you call on a RIA Services domain context. There are really two programming models, but I’ll just show one for now as the other is very similar.

When you call DomainContext.Load, RIA services executes the retrieval in the background and the call is non-blocking to the calling thread. But often you need to get those results, do some processing on them, and then move on to make another query or do something else.

An easy way to handle things is to use an overload of Load (and SubmitChanges) that takes a callback delegate that will be called when the async work is complete. This model is slightly different than the two other familiar async patterns in .NET: BeginXXX/EndXXX method pairs and XXXAsync/XXXCompleted method/event.

In the RIA Services async pattern, you can pass an Action<XXX> delegate to the async method you are calling, and that target method will be executed when the async operation is complete. It will pass you results and any error information if applicable.

In the case of a Load call, the code would look something like this:

private void RetrieveAndProcessTasks()
{
    TasksDomainContext context = new TasksDomainContext();
    EntityQuery<Task> query = context.GetTasksQuery();
    Action<LoadOperation<Task>> completeProcessing = delegate(LoadOperation<Task> loadOp)
    {
            if (!loadOp.HasError)
            {
                ProcessTasks(loadOp.Entities);
            }
            else
            {
                LogAndNotify(loadOp.Error);
            }

    };
    LoadOperation<Task> loadOperation = context.Load(query.Where(t=>t.EndDate > DateTime.Now),completeProcessing,null);
}

private void ProcessTasks(IEnumerable<Task> entities)
{
    // Do what you need to do
}
private void LogAndNotify(Exception error)
{
    // Log the error and notify user if appropriate
}

Before calling Load on the domain context, you set up an Action<LoadOperation<T>> delegate to point to a handling method with the signature void TargetMethod(LoadOperation<T> op). In this example I do that with an anonymous method that checks whether there are any errors, and if not hands off to a processing method the entities that were returned. If there is an error, it hands off the Exception to a handling method as well.

Then it is just a matter of calling Load and passing that delegate as a second argument (the first is always the EntityQuery you want to execute), and a final argument that is an arbitrary state object, similar to the Begin/End signatures of the original .NET async pattern.

Unfortunately there is no easy way to shield you entirely from the async nature of service calls in Silverlight if you want to do something other than data bind to the results immediately after the load occurs.

AS I’ve mentioned in a previous post, I’m writing a 10(+?) part series on WCF RIA Services on the Silverlight Show site. The second article is now available here:

 http://www.silverlightshow.net/items/WCF-RIA-Services-Part-2-Querying-Data.aspx

This article shows goes into more depth on defining query methods in your domain service and how to execute them programmatically on the client.

So check it out!

I’ve published the first in a series of ten articles on WCF RIA Services over on the SilverlightShow. This one just runs through the key concepts and a simple end to end demo. Future articles will dive into the specifics of all the various capabilities of WCF RIA Services. You can find the full article here:

http://www.silverlightshow.net/items/WCF-RIA-Services-Part-1-Getting-Started.aspx

I gave a talk today at the NOVA Code Camp on the MVVM pattern in WPF and Silverlight.

Some of the key highlights and takeaways are:

• MVVM is based on the Presentation Model pattern
• MVVM is all about separation of concerns and loose coupling
• The ViewModel’s responsibility is to offer up state to the view in the way the view wants to see it
• The ViewModel contains and manipulates state
• View.DataContext = ViewModel is the relationship between view and ViewModel
• The View data binds properties on elements to properties on the ViewModel
• The View elements fire commands via data bindings on command properties on the ViewModel to manifest behavior in the ViewModel
• Parent ViewModels can contain child ViewModels to allow the views to compose via DataTemplates
• ViewModels can contain logic that manipulates the state including loading/updating state, validating state, computing values, and other kinds of logic that is not readily accessible in the model

A good source of info and examples on MVVM is the upcoming Prism 4 release, which already has public drops that include the MVVM QuickStart and a future drop will contain a more complicated MVVM Reference Implementation (bigger sample).

You can grab the slides and demos here:   Slides    Demos

UPDATE 6/5/2010: Added a couple more below on performance and windowing based on discussion with Silverlight/WPF insiders.

I’ve been hearing a lot of people talking about WPF lately as it if was a poor elderly relative that is terminally ill. “Yeah, poor Fred, he always showed so much promise, but never really amounted to anything. And now he is on his way out…”

I think this perspective on WPF is rubbish, especially for the next couple years at least. Images of Monty Python’s Bring Out Your Dead scene pop to mind, except WPF is vibrant and ready for a marathon, not laying in a cart.

Part of the problem is that as developers we tend to jump on the newest shiniest toy on the playground and forget there are others that are just if not more capable.

The main reason for people talking this way is Silverlight 4. First let me start by saying I love Silverlight 4. The improvements made in this release are fantastic, and do significantly close the gap in capabilities between WPF and Silverlight. And for an awful lot of business and consumer applications out there, Silverlight 4 is now good enough to build those apps using Silverlight instead of WPF. So I am not in any way trying to bash Silverlight, just point out that it is not the only shiny toy on the playground.

The gap in capabilities is still there in substantial ways for certain scenarios that you can’t easily write off by just saying you will build all your business desktop applications in Silverlight now. At some point, maybe a couple more releases of Silverlight away, there will be parity. In fact, by that point, I hope and think the technologies will merge and for a lot of what you do you will just be using the same set of libraries from the framework, and will choose from a range of deployment modes for your application and its host. If that is the case, it doesn’t matter what you call it, it doesn’t make WPF any less relevant today. We already have somewhere between 60-80% code equivalence in WPF and Silverlight 4 depending on whether you focus on the core UI and supporting code or the hosting code.

The main feature that people point to in SL4 that they try to say “See, we don’t need to bother with WPF now” is Out-Of-Browser (OOB) elevated trust. The first important point here is that it is “Elevated” not “Full”. You have the ability to do a lot of things you couldn’t do before based on that elevated trust, but there are still a lot of things you could be blocked from doing that would be no problem in a WPF application. Additionally, for almost all the new things in Silverlight 4, you can look at the corresponding capability in WPF and realize that Silveright is still the “challenged” sibling. Even though these new features cover the 80% for most apps, that remaining 20% might be just the thing you need, and not having it could either cost you a lot of time and money trying to compensate, or penalize your users because of the lack of capability.

Let me run through some of the key differences that make me hesitate to jump too quickly to Silverlight 4 when choosing a client application technology.

File access:

WPF – Unlimited

Silverlight – User profile special folders (My Documents, My Pictures, My Videos, etc.)

Printing:

WPF – Many options, access to Print Dialog, control print queues, etc

Silverlight – Print a UI element programmatically

Documents and editing:

WPF – Flow and fixed document, RichTextBox editing and integration with flow document

Silverlight – RichTextArea control with most functionality of the WPF RichTextBox

Commands:

WPF – Support for raising commands on buttons, hyperlinks, menu items; input bindings tied to commands for keyboard shortcuts; routed commands implementation in the box

Silverlight – Support for raising commands on buttons, hyperlinks, context menu items, no input bindings, no routed commands

Communications:

WPF – Full range of WCF capabilities, able to consume and host services of any kind, full range of security options and other WS-* protocols, REST, low level communications of many kinds

Silverlight – Limited subset of WCF client capabilities, no ability to expose a service from the client, unsecured TCP or HTTP protocols, duplex less capable than WPF clients (polling HTTP or unsecured TCP only), some socket level capabilities, have to take cross domain considerations into mind in most deployment scenarios.

Clipboard:

WPF – Any kind of serializable objects

Silverlight – Text only

Drag Drop:

WPF – Any kind of object

Silverlight – Files only

External devices:

WPF: Anything with a driver, COM, Win32, or communications protocol

Silverlight: Webcam, camera, microphone, and devices with a COM API or compatible communication protocol

Input:

WPF – Keyboard, mouse, pen, touch no real limitations

Silverlight – Must be OOB elevated trust full screen to have full keyboard access

Performance (anecdotal, but consistent with what I have seen):

WPF – Better hardware acceleration because it can fully leverage the DirectX platform

Silverlight – Hardware accelerated on Windows, but not as deeply as WPF

Windowing Control:

WPF – Party on. Open as many windows as you want, programmatically control size, position, etc. anytime

Silverlight OOB – limitations on when and where you can size/position windows, can’t have multiple open non-modal windows

The bottom line is that if your client application is mainly a front end for back end data – Silverlight 4 is perfect and sufficient. But if your client application needs deeper integration with the client machine and other things that reside client side, it may be possible to get it done with SL4 elevated trust OOB, but it will likely be more challenging and you may hit brick walls that kill your productivity or functionality. You really need to do a good up front requirements analysis and if you have any significant interaction with client machine resources, WPF is still going to make your life easier.

That being said, at the current time, WPF is the “Challenged” sibling in terms of a couple of newer technologies. The WCF RIA Services capabilities for generating client side code and having the DomainDataSource is very attractive for a broad range of business application use cases. That will be coming in a future release for WPF, but in the meantime, Silverlight has the leg up there. Additionally, MEF added some convenience classes in Silverlight 4 that didn’t make it back into the main .NET Framework that make certain composition scenarios a little easier and cleaner to code. But that is less of a leg up than the RIA Services part.

As developers and architects, we need to make good choices based on our requirements. Not just jump on the latest greatest thing that everyone is talking about. If you build on WPF today, you are not really going to be blocked from doing anything you need to do. You might not get all the new shiny toys as quickly because WPF releases with the Framework every few years, whereas Silverlight looks to be sticking to an annual release cycle. But I don’t think any WPF apps are ever going to become stuck in that technology. I think as Silverlight matures even further, we will get to a place where you can just change deployment modes if you want a web based, cross-platform, security context limited version of your app and it will be what we call a Silverlight app today. If you want a deeply integrated version with the desktop you’ll choose a deployment mode that matches what a WPF app is today.

But if you are getting the feeling that you should avoid WPF because it might go away or because Silverlight is the better platform, or that WPF code will become obsolete, I think you are getting the wrong impressions and should rethink.

Yesterday I posted about Prism 2.2’s release and said there would be a Prism 4.0 first drop soon. It happened sooner than I thought.

You can go grab the drop bits here:

http://compositewpf.codeplex.com/releases/view/46407

First a big thanks to the p&p Prism team for continuing the trend of getting bits out early and often to the community to drive the direction of what they produce. They’ve only been working on this a short time, and these QuickStarts are a great starting point that people can refer to already and provide feedback, as well as not having to wait a few more months for the finished product to come out.

The code that is in this drop is completely additive to what is in Prism 2.2, and is more of a very early look at some of the guidance that will ship with Prism 4 when it is done. Specifically, all that is there so far are two QuickStarts. One is an MVVM QuickStart that demonstrates the use of the MVVM pattern in a standalone Silverlight survey application that itself does not depend on Prism at all. The idea is to show the use of MVVM in a couple of its simplest forms – one being a top level view (composite view) that has its own view model that provides the state for the view, and the other being several dynamically generated views (through data templates) that each have their own instance of a view model supporting them.

The ViewModel QuickStart is not meant to say this is the only way to get it done. MVVM has many variations and flavors and ways of creating and relating the views and view models. But this QuickStart is really to help those who are pretty new to the pattern to see a running application that has one of the primary ways of structuring MVVM for this scenario, as well as to see the nature of some of the responsibilities and things that a ViewModel is supposed to do for a view.

Some of the things the ViewModels in the QuickStart do that are normal responsibilities of a ViewModel:

• Mapping of data from the model into the ViewModel properties so that it is readily available to the view in the form the view needs it without having to couple the view to the model itself or do conversions in the view to display the model data
• Type or value conversions from the model to the view so the view doesn’t have to do those conversions
• Validation logic that is specific to the presentation (i.e. max input length exceeded) and that does not or should not be part of the model
• Exposing properties that are not part of the model themselves (i.e. character count remaining based on current input)
• Invoking validation logic that does reside on the model itself

Right now the code does not have as liberal of comments as it should be the time it is done to explain some of the choices being made and why they are there in the ViewModel classes. But realize this is just a first early drop to start sharing the work in progress and get feedback.

The second QuickStart that is in this drop is a modularity QuickStart that shows the changing out MEF as the dependency injection container instead of using Unity. MEF has its own programming model for indicating dependencies through imports and offering up types through Export. What this QuickStart does is adds a MEFExtensions library that is structured very much like the UnityExtensions library in Prism 2.2 and prior. This library provides the Service Locator pattern-based bridge between the rest of the Prism code and the particular dependency injection container you choose to use. Prism remains container agnostic and allows you to choose from the built-in implementation for Unity, now adding an implementation for MEF, or you can write your own Service Locator bridge for other containers as well.

What I like about what they have done is that the code for the core Prism parts of your application look virtually identical to how they would look if you were (or are already) using Unity.

Instead of using the UnityBootstrapper base class for your own application Boostrapper, if you want to use MEF, you’ll just change out and use MefBootstrapper. The base class provides the same overrides (plus one new one for InitializeShell that gives you the same two-phase construction option that you have for the container and modules as well), so a lot of what you would normally put in your bootstrapper will look exactly the same, modulo those things that touch the container directly. Instead of registering and resolving types against the Unity container, you would be manipulating MEF catalogs to add types that are not automatically discovered, and could SatisfyImports to get instances of parts out of the container if they were going to be used directly in the bootstrapper.

The main differences in your module classes are that they will use MEF constructs to indicate their dependencies and to export their type and or contract to the MEF container. The QuickStart defines a strongly typed ModuleExport attribute for modules so they can provide metadata about their name and dependencies:

 

[ModuleExport(typeof(ModuleD))]
public class ModuleD : IModule
{
    private IModuleTracker moduleTracker;

    [ImportingConstructor]
    public ModuleD(IModuleTracker moduleTracker)
    {
        this.moduleTracker = moduleTracker;
        ...
    }

    public void Initialize()
    {
       ...
    }
}

 

You can of course also use property imports with the Import attribute in lieu of or in addition to ImportingConstructor, although I still favor constructor injection so that the dependency is available in the constructor for use.

For your Views, ViewModels, etc. they can just use standard MEF constructs, of which there are many good examples out there.

Here is a quick look at what the modularity QuickStart looks like:

 

It demonstrates loading of modules at startup, on-demand, based on references, directory scan, and configuration all in one quickstart instead of in separate ones like existing Prism QuickStarts. But it removes any other aspects of Prism such as regions and commands from the mix.

Even though there is a Silverlight version in the drop, it doesn’t currently work, so we will have to wait for the next drop to see what it looks like for XAP loading as modules. But the code will be very similar.

If you want to play with the bits and get in on the discussion and feedback, I’d encourage you to jump into the discussion forum on the CodePlex site. I’m also working closely with the team as an advisor, so you can also contact me directly (@briannoyes on twitter for quick contact).

For those who may have missed it and are moving into .NET 4, Prism 2.2 just released a couple days ago.

You can get a copy from the CodePlex site: http://compositewpf.codeplex.com/ for now, although it should make its way to the MSDN pages on Prism as well.

Functionally there is nothing new in this release. It is really just to have an officially released, and more important, tested and supported version of Prism for .NET 4.0 and Silverlight 4.0 released versions. The WPF version (desktop) is still set to target .NET 3.5 so you don’t have to migrate to use it, but will work fine with .NET 4.0 as well if you change your target framework in the project settings if you want to compile against 4.0.

You’ll also notice that the Really-Big-Long-Name Composite-Application-Guidance-For-WPF-And-Silverlight is fading away. Not sure what legal hoops the team had to jump through, but its just being referred to as Prism now. Long live the community will! I’m sure there will still have to be some back referencing to keep the names tied together, but as I understand it, the next release, which will be called Prism 4, will be called just that.

I’ll be blogging more about Prism 4 as the features gel a little more. For the most part, if you are just getting started with Prism, you can safely start with 2.2, and you will be able to leverage new features as they are added in Prism 4. A couple of the major thrust areas are in providing more guidance around the MVVM pattern and implementation and integration of MEF as an alternative to Unity as the container for modularity and dependency injection. But the MEF pieces will be added on as an option. If you write your app against Unity now, it will still work with Prism 4. And if you want to move over to MEF, it would require some changes in your module code and definitely in the way you do your dependency injection, but is not a substantially different model.

You can read a little more about where things are headed here: http://blogs.msdn.com/b/simplifying_patterns_and_practices/archive/2010/03/15/prism-a-look-ahead.aspx 

Additionally, keep your eyes on the codeplex site about. Starting soon you will see public drops of the code in work for Prism 4 including some of the QuickStarts.

I’ve been hearing a lot of people talking about WPF lately as it if was a poor elderly relative that is terminally ill. “Yeah, poor Fred, he always showed so much promise, but never really amounted to anything. And now he is on his way out…”

I think this perspective on WPF is rubbish, especially for the next couple years at least. Images of Monty Python’s Bring Out Your Dead scene pop to mind, except WPF is vibrant and ready for a marathon, not laying in a cart.

Part of the problem is that as developers we tend to jump on the newest shiniest toy on the playground and forget there are others that are just if not more capable.

The main reason for people talking this way is Silverlight 4. First let me start by saying I love Silverlight 4. The improvements made in this release are fantastic, and do significantly close the gap in capabilities between WPF and Silverlight. And for an awful lot of business and consumer applications out there, Silverlight 4 is now good enough to build those apps using Silverlight instead of WPF. So I am not in any way trying to bash Silverlight, just point out that it is not the only shiny toy on the playground.

The gap in capabilities is still there in substantial ways for certain scenarios that you can’t easily write off by just saying you will build all your business desktop applications in Silverlight now. At some point, maybe a couple more releases of Silverlight away, there will be parity. In fact, by that point, I hope and think the technologies will merge and for a lot of what you do you will just be using the same set of libraries from the framework, and will choose from a range of deployment modes for your application and its host. If that is the case, it doesn’t matter what you call it, it doesn’t make WPF any less relevant today. We already have somewhere between 60-80% code equivalence in WPF and Silverlight 4 depending on whether you focus on the core UI and supporting code or the hosting code.

The main feature that people point to in SL4 that they try to say “See, we don’t need to bother with WPF now” is Out-Of-Browser (OOB) elevated trust. The first important point here is that it is “Elevated” not “Full”. You have the ability to do a lot of things you couldn’t do before based on that elevated trust, but there are still a lot of things you could be blocked from doing that would be no problem in a WPF application. Additionally, for almost all the new things in Silverlight 4, you can look at the corresponding capability in WPF and realize that Silveright is still the “challenged” sibling. Even though these new features cover the 80% for most apps, that remaining 20% might be just the thing you need, and not having it could either cost you a lot of time and money trying to compensate, or penalize your users because of the lack of capability.

Let me run through some of the key differences that make me hesitate to jump too quickly to Silverlight 4 when choosing a client application technology.

File access:

WPF – Unlimited

Silverlight – User profile special folders (My Documents, My Pictures, My Videos, etc.)

Printing:

WPF – Many options, access to Print Dialog, control print queues, etc

Silverlight – Print a UI element programmatically

Documents and editing:

WPF – Flow and fixed document, RichTextBox editing and integration with flow document

Silverlight – RichTextArea control with most functionality of the WPF RichTextBox

Commands:

WPF – Support for raising commands on buttons, hyperlinks, menu items; input bindings tied to commands for keyboard shortcuts; routed commands implementation in the box

Silverlight – Support for raising commands on buttons, hyperlinks, context menu items, no input bindings, no routed commands

Communications:

WPF – Full range of WCF capabilities, able to consume and host services of any kind, full range of security options and other WS-* protocols, REST, low level communications of many kinds

Silverlight – Limited subset of WCF client capabilities, no ability to expose a service from the client, unsecured TCP or HTTP protocols, duplex less capable than WPF clients (polling HTTP or unsecured TCP only), some socket level capabilities, have to take cross domain considerations into mind in most deployment scenarios.

Clipboard:

WPF – Any kind of serializable objects

Silverlight – Text only

Drag Drop:

WPF – Any kind of object

Silverlight – Files only

External devices:

WPF: Anything with a driver, COM, Win32, or communications protocol

Silverlight: Webcam, camera, microphone, and devices with a COM API or compatible communication protocol

Input:

WPF – Keyboard, mouse, pen, touch no real limitations

Silverlight – Must be OOB elevated trust full screen to have full keyboard access

 

The bottom line is that if your client application is mainly a front end for back end data – Silverlight 4 is perfect and sufficient. But if your client application needs deeper integration with the client machine and other things that reside client side, it may be possible to get it done with SL4 elevated trust OOB, but it will likely be more challenging and you may hit brick walls that kill your productivity or functionality. You really need to do a good up front requirements analysis and if you have any significant interaction with client machine resources, WPF is still going to make your life easier.

That being said, at the current time, WPF is the “Challenged” sibling in terms of a couple of newer technologies. The WCF RIA Services capabilities for generating client side code and having the DomainDataSource is very attractive for a broad range of business application use cases. That will be coming in a future release for WPF, but in the meantime, Silverlight has the leg up there. Additionally, MEF added some convenience classes in Silverlight 4 that didn’t make it back into the main .NET Framework that make certain composition scenarios a little easier and cleaner to code. But that is less of a leg up than the RIA Services part.

As developers and architects, we need to make good choices based on our requirements. Not just jump on the latest greatest thing that everyone is talking about. If you build on WPF today, you are not really going to be blocked from doing anything you need to do. You might not get all the new shiny toys as quickly because WPF releases with the Framework every few years, whereas Silverlight looks to be sticking to an annual release cycle. But I don’t think any WPF apps are ever going to become stuck in that technology. I think as Silverlight matures even further, we will get to a place where you can just change deployment modes if you want a web based, cross-platform, security context limited version of your app and it will be what we call a Silverlight app today. If you want a deeply integrated version with the desktop you’ll choose a deployment mode that matches what a WPF app is today.

But if you are getting the feeling that you should avoid WPF because it might go away or because Silverlight is the better platform, or that WPF code will become obsolete, I think you are getting the wrong impressions and should rethink.