I was recently interviewed on the Silverlight TV show hosted by John Papa and the episode went live today.

http://channel9.msdn.com/shows/SilverlightTV/Understanding-the-Value-of-Prism-Silverlight-TV-37/

In the interview, we discuss some of the motivations for adopting Prism:

• Managing large projects
• Distributed teams
• Packaging functionality for different deployments per customer
• Separation of concerns for maintainability
• Testability
• Extensibility

I quickly walk through the features and how they manifest themselves in your solutions. I also discuss a little of what the team is working on in Prism 4 – specifically the MVVM pattern and using MEF for modularity.

Check it out and let me know what you think!

Last night I spoke to a great crowd at a joint meeting of the San Diego Connected Systems and Architecture SIGs. I talked about WCF RIA Services and focused on the internals of what is going on with deferred execution queries, metadata for entities, and the services under the covers, as well as exposing OData, SOAP, and JSON endpoints and consuming them.

Here are the slides and demos.

I gave a talk on Monday evening at the Los Angeles .NET Users Group on WCF RIA Services, MVVM, and MEF. I was insanely ambitious thinking I could cover all those in one talk, but it was a fun talk nonetheless. It was a very interactive crowd with a lot of great questions about Silverlight in general, RIA Services, Entity Framework and other broader technology topics.

Here are the slides and demos.

In conjunction with the 10 part series on WCF RIA Services in am part way through writing for the Silverlight Show, I also did a short interview with them about RIA Services, Silverlight in general, and my background. You can find that interview here: http://www.silverlightshow.net/items/SilverlightShow-Interview-Featured-Article-Author-Brian-Noyes.aspx

Not too long ago I made the plunge and bought a MacBook Pro, the first Mac I have ever owned. I did so for two reasons. First and foremost, I am starting to develop applications for the iPhone and iPad (two devices I can’t live without), and developing on a Mac is the only choice thanks to the closed platform and development tools approach of Apple. Secondly, I thought it would be interesting to see what computer life is like on the other side of the fence. I’ve heard so many stories of how great the Mac is, I thought I would try to experience it first hand.

So for the last month I have tried using my MacBook Pro as my primary machine – not booting to Windows, but running Mac OS X and using Parallels to get to the Windows apps I can’t live without.

After a month, I’m switching back to my Dell Latitude E6500 as my primary machine and my MacBook Pro will just be used for reason #1 – developing for iPhone/iPad.

When I tweeted (@briannoyes) that I was switching back, I got a lot of “why??” questions, so I thought I would share my experience for others who are pondering a similar change.

Some important caveats up front:

• I am first and foremost a Windows developer and software architect. That is my profession and my passion and what I have been focusing on for almost two decades.
• I have dozens of Windows applications that I used at least once a month and at least 20 or so that I use every week. While I realize there are many equivalent Mac programs for many of those, I don’t want to have to buy all of those, and for many there is not (i.e. Windows development tools).
• I don’t just work on one machine and have no intention of switching all of my computing to Apple. While I love my iPad and iPhone, I have a Windows 7 desktop machine in my home office that I use when not traveling, and when traveling (75%+ of my time) I often carry a second laptop for various reasons and that one would certainly be a Windows machine.
• From a performance perspective, my point of comparison and what I have switched back to is a 6 month old Dell Latitude E6500 that is maxed out. My MacBook Pro has slightly better hardware specs (i7 processor), but same 256 GB SSD drive and 8 GB memory.
• I was afraid of using Boot Camp to boot to Windows directly because of witnessing and hearing about numerous projection issues when running Windows through Boot Camp on Mac Books. A significant majority of my professional work involves projecting (teaching, consulting, presenting at conferences and user groups). I can’t travel with a machine I can’t trust will project anywhere through any projector with no issues.
• I’ve been using Office 2010 for a while, so that is my standard of comparison for routine business tasks (email, writing, presentations, spreadsheets).

So what did I like:

• General user experience is very nice at the OS level.
• iTunes runs much smoother on the Mac than on Windows
• Parallels integration with the Mac OS is very smooth and seamless
• Er… ummm… OK, nothing else jumping out that I found superior to anything I do on Windows 7.

What I did not like:

• Built in apps (email, calendar, etc.) had no where near the functionality or user experience of Office 2010. Office 2008 for Mac is not as good either, and I still have to co-exist with several Windows PCs. Worrying about file conversions and potential data loss is just not worth it.
• A lot of my Windows apps could not run from the shared Mac OS folders, so had to move things onto the virtual C: drive a lot to get things to run, aggrevating file synchronization issues and leading to duplicate files and drive usage.
• Keyboard lacks many common keys that PC keyboards have (Del, Home, End, PgUp, PgDn, etc). You have to use the Fn key to get other keys to do those things, and you have to use the Fn key to get the function keys to act as function keys instead of volume, etc shortcut keys. These keys are all way too important to me as a coder to have to use the extra key to get to them, especially since I also work a lot on PCs and have to switch my brain back and forth. Likewise the differences of what the Control, Alt/option, and Command keys do in Mac vs Windows (in parallels) drive me bonkers trying to keep straight. Many a wasted minute thinking I copied things to the clipboard and I didn’t or getting things to select correctly.
• Perf: even though the Mac had a better processor and equal memory / disk, everything felt a lot more sluggish on it, and I’m not just talking about the Windows apps running in Parallels. Copying files to external USB drives (which I had to do a lot for syncing files between machines) was significantly slower than on PC.
• File synchronization: I use Dropbox to sync files between my machines, but the difference in file systems led to some oddities that that were annoying at best and could lead to data loss if not closely managed. Syncing with external drives also took closer attention than I wanted to give it. I don’t want to have to think at all about moving files around, and from PC to PC I don’t.

So bottom line, I decided I can’t live on a Mac as my primary machine for the reasons outlined above. I am convinced that if you only have to use one machine and are willing to invest in getting all the apps you need as Mac apps, and can live 80% or more of your computer life using Mac apps, then it is a nice platform. That is just not me, so I am happily back in my comfort zone on all Windows 7 machines + a MacBook Pro as an iPad/iPhone development box.

The third part of my series on WCF RIA Services went up a few days ago, you can check it out here:

http://www.silverlightshow.net/items/WCF-RIA-Services-Part-3-Updating-Data.aspx

This one starts off with a quick coverage of one important aspect of querying that I did not have room for in Part 2 – expression trees and deferred execution, and what they can do for you with RIA Services. I show how you can formulate a query on the client side based on the expression tree returned by a query method and that is what executes on the server side.

Then I get into the way updating (insert, update, and delete really) works in RIA Services. I discuss the way the domain context caches data and tracks its changes, and then only sends the modified entities back in a batch when you call SubmitChanges on the domain context. I also talk a little about the async API of the domain context, which I then followed up on with this post:

http://www.softinsight.com/bnoyes/2010/06/29/QueryingWCFRIAServicesAndHandlingAsyncResults.aspx

Enjoy!

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);
} privatevoid ProcessTasks(IEnumerable<Task>
entities) { // Do what you need to do } privatevoid 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))] publicclass ModuleD
: IModule { private IModuleTracker moduleTracker; [ImportingConstructor] public ModuleD(IModuleTracker
moduleTracker) { this.moduleTracker = moduleTracker; ...
} publicvoid 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).