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).

Thursday, June 03, 2010 7:29:01 PM (GMT Standard Time, UTC+00:00)
Comments [4]  | 

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.

Wednesday, June 02, 2010 9:25:28 PM (GMT Standard Time, UTC+00:00)
Comments [6]  | 

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.

Tuesday, June 01, 2010 7:09:54 PM (GMT Standard Time, UTC+00:00)
Comments [15]  | 

Tomorrow night I am giving a talk on WCF Best Practices at the Omaha .NET Users Group.

The talk covers a bunch of things we at IDesign have learned over about 7+ years of working with WCF since the Indigo days before it was even public. Best practices need a context, and I cover contexts where each of the recommended practices make sense in the talk, but most of the bullets can be followed without a lot of context – I’ve structured it to be things you should do by default without really needing to know why, and context is needed to say when not to do these things as opposed to the other way around.

If you would like to take a look at the slides and have any comments or questions about this recommendations, you can ping me here or on twitter @briannoyes. The demo code also shows examples of almost everything mentioned in the slides, even though the actual functionality of the app and service is extremely simple CRUD, the talk is more about structural and configuration things you should be doing in your WCF service application architecture.

You can grab the Slides and Demos here:    Slides   Demos

Wednesday, May 26, 2010 11:19:15 PM (GMT Standard Time, UTC+00:00)
Comments [5]  | 

I’ve just scheduled a 3 day class in Zurich on WPF Architecture. You can find the details and outline here:

http://professional-developer-training.net/items.aspx?catId=c12

This class is different than most WPF training in that it focuses not on the nuts and bolts of putting together the UI, but instead focuses on what is behind the scenes with UI patterns including MVVM, using Prism for composite apps, and how to tie it all together with commands, data binding, and events.

If you want a great WPF class in a fantastic location, check this one out.

Sunday, May 02, 2010 9:48:18 PM (GMT Standard Time, UTC+00:00)
Comments [21]  | 

I did an interview for DZone at DevTeach Toronto a few weeks ago and that is now available online here.

In the interview I described what the ViewModel pattern is all about and how it manifests itself in Silverlight and WPF apps. I also talked about what I found most interesting in Silverlight 4, specifically the enhancements in data binding and commanding that close the gap a lot between WPF and Silverlight and provide the glue that is needed to really do MVVM well.

I also talked about Prism and what it provides for you: Commands, loosely couple events, UI Composition, and Modularity.

There is also a very short (~1 minute) demo that shows some of the characteristics of the code of an MVVM implementation.

Hope you enjoy it.

Thursday, April 22, 2010 5:04:57 PM (GMT Standard Time, UTC+00:00)
Comments [7]  | 

This week I gave three talks at the Visual Studio Connections conference launch event for Visual Studio 2010. The topics included using Workflow 4 in service applications, writing custom activities in Workflow 4, and unit testing services and workflows.

You can download the slides and demos for each here:
VWF01: Workflow 4 Service Applications      Slides   Demos
VWF02: Workflow 4 Custom Activities         Slides   Demos
VWF03: Unit Testing Workflows and Services  Slides   Demos

It was great to see the interest and enthusiasm surrounding the launch of VS 2010. There is so much great new stuff there and in the .NET 4 framework to be excited about, as well as the launch of Silverlight 4.

I think one of the most important things for companies to keep in mind is that they can move to VS 2010 safely and keep building and supporting apps for .NET 3.5 and even back to 2.0 for as long as they need to for their deployment environments. But meanwhile they can start benefiting immediately from the big improvements in the VS 2010 IDE, including better code editing features, significantly improved designer for WPF and Silverlight, faster loading References window, IntelliTrace and so much more.

Friday, April 16, 2010 10:37:46 PM (GMT Standard Time, UTC+00:00)
Comments [15]  | 

Always a nice way to start the new year, with the email telling me I have been awarded Microsoft MVP for another year. This makes 7 years running, a good streak that I hope to continue.

Being an MVP means a lot of things to a lot of different people. Things I love about the program are numerous:

• Direct access to product team members that really seem to listen and respond based on the fact that you are an MVP
• Opportunities to participate in early adopter events, SDRs, feedback sessions to help shape where Microsoft takes its developer products
• Opportunities to teach and evangelize those products to the community
• Recognition of expertise from customers based on the title
• MSDN and TechNet subscriptions

This year I’ll be continuing to have a split focus between both connected systems (WCF and WF in particular) and client technologies (Silverlight and WPF). Lots of conferences, classes, user groups, code camps and things like that already planned or to be planned. Also a lot of writing this year (more on that in a subsequent post) and plan to get more MSDN webcasts going this year as well.

Its going to be an exciting year and an exciting decade. Bring on the technology!

Friday, January 01, 2010 3:37:43 PM (GMT Standard Time, UTC+00:00)
Comments [3]  |