• Accueil
• Actualités
• Logiciels
• Emplois
• Blogs
• A propos

Articles Scrum

A simple WCF service with username password authentication: the things they don’t tell you

[22/03/10]

The WCF framework is gigantic. It has such an enormous amount of possibilities that it’s pretty easy to get completely lost. For our scenario we needed just a small basic subset. Our application provides a set of services which are consumed by a diversity of clients which have to tell who they are by providing a custom  username and password. There are loads and loads of documents and manuals to be found on the web but I didn’t find anything which gave me the complete story. Most of them follow all kinds of sidesteps in other parts of the rich WCF framework. Things we didn’t need at all, the things we needed to get our stuff to work were either omitted or only mentioned briefly in a comment.

This post tries to describe the full story. It will try to keep quiet on all noise on other cool, but unneeded, features. This information is assembled from a rich variety of stuff on the web and error messages provided by the WCF framework itself. The latter are often quite to the point and provide a lot of essential information. This post is just a kind of cookbook recipe, I don’t claim to understand every detail and would appreciate any comment to further clarify the details.

The service

The service is an ASP.NET service, hosted by IIS and configured in the system.ServiceModel part of the web.config.

The endpoint address is the root of the IIS site in which it his hosted. To use username authentication you need to use wsHttpBinding. The services functionality is described in the ICustomerDeskOperations contract.

In the binding you specify the credential type as username.

In the servicebehaviour you set up how the username is going to be validated

The username is custom validated. This is done by the FarmService.Authentication.DistributorValidator class in the FarmService assembly. This class inherits from WCF class UserNamePasswordValidator and overrides the Validate method.

The method validates the incoming username and password in a repository and throws appropriate exceptions when needed. This is really custom code. As long as you don’t throw an exception the service invocation will be accepted.

So far this could have been a copy of many a story on the web. Except for one detail which is absolutely essential. For username password authentication to work your server hosting the service needs an X509 certificate. Else all service invocations will fail. This certificate is specified in the service behavior.

<serviceCertificate findValue="Farm" storeLocation="LocalMachine" storeName="TrustedPeople"  x509FindType="FindBySubjectName"/>

First you need a certificate. Instead of buying one (which is bound to a specific server address and thereby as good as useless for testing purposes) you can create your own. The .net framework comes with tools to generate these and there are several tutorials how to use these tools. Far more easier is selfcert a pluralsight tool which takes care of the whole process in a couple of clicks.

What they don’t tell you here is that you have to run the tool as administrator, else it will crash most ungracefully. What the tool is also unclear about is where to store the generated certificate. By default it is stored in MyStore. When validating the certificate it’s trustworthiness depends on the location it is stored. When the store is not trusted a chain of validation is started. Instead of setting up a chain of certificates you can also directly store your certificate in a trusted store.

With these settings the certificate is stored in a trusted location. The name and location match the settings in the service behavior

Troubles don’t end here. After a while, like logging in the next time, the service host will start complaining it cannot find the private key of the certificate with a “Keyset does not exist” error message. What happens it that the service no longer has the access right to read the certificate. What helped me was explicitly setting rights on the certificate’s private key file.

Here I am using a blunt axe by just allowing everybody read rights on the certificate’s private key file. I’m no security expert but I am aware this is absolutely not the way to do things. But hey, I only want to build a service, never asked for this certificate stuff and the only thing I want to do here is get that out of the way in the development process.

Now the service is ready to be consumed by a client

The client

To consume this service add a service reference in the client. The mexHttpBinding in the service configuration enables to read all metadata form the service without any credentials.

Setting up a connection to the client requires some fiddling. Again not all of these settings are clear by default.

First we need an endpoint. This is assembled from the url in the client’s configuration, here a constant Farm.FarmUrl. For the custom username authentication to work the endpoint also needs an EndpointIndentity. According to the sparse msdn documentation this is to prevent phishing. The fact that the identity was needed and the parameter had to be the certificate’s name was suggested by the WCF error messages.

The security is set according to the security settings we have seen in the service. Both the username and password are set in UserName property of the ClientCredentails.

Wrapping up

This is it. Now our service and clients are talking. But it took far to much effort to find the right settings. The number is not great, but they all were found to be essential. Finding the right was a process of endlessly weeding out all sidesteps. I hope this well help you to get it done a little faster.

Pow! Biff! Wham! Splat!

[22/03/10]

No, this post is not a tribute to the fabulously kitschy Batman TV series (1966-1968) starring Adam West and Burt Ward. Or a tribute to the onomatopoeic sounds for which it and the Batman comics were famous. This show did however come to mind when I was trying to solve a PowerShell problem and ran across the wonderfully-named splatting (@) operator introduced in PowerShell v2. Before we get to the splatting operator, let’s look at the problem that it was designed to solve.

With psake v2 came the change from a PowerShell script to a PowerShell module. Modules provide a lot of advantages over a simple script. For psake the compelling advantages were better control over scoping and better integration with PowerShell’s help system. One disadvantage was that you now had to first import the module before you could use psake.

ASIDE: If you’re wondering about the “James@EDDINGS psake [master +0 ~1 -0]>” stuff, I’ve installed Mark Embling’s awesome PowerShell Git Prompt, which is simply a custom PowerShell prompt. It tells me that my user is James, I’m logged into my main dev machine (EDDINGS), I’m in the psake directory (c:\dev\oss\psake) – though I only display the last part of the path for brevity, I’m on the “master” branch, I have no pending additions (+0), no pending changes (~0), and no pending deletions (-0). (I need to see if I can hack in how many commits forward or back I am from a tracked remote.) Everything in brackets is omitted if it isn’t a Git directory. Another good set of Git/PowerShell scripts is Jeremy Skinner’s PowerShell Git Tab Expansion for completing common command names, branch names, and remote names. If you are using Git and PowerShell, I would highly recommend both Mark’s and Jeremy’s scripts. If you don’t want to copy/paste them together, you can grab them from my random collection of PowerShell scripts here.

Note how we had to first call “import-module” before we could use psake. For some people, they install the latest version of psake in some well-known location, import the module, and then run it from there until the next update comes out. For others (e.g. me), we like to version psake along with our source code and other dependencies. Importing a project-specific copy of psake becomes a headache very quickly. So I wrote a little shim script to register psake, run it, and then unregister it.

# Helper script for those who want to run
# psake without importing the module.
import-module .\psake.psm1
invoke-psake $args
remove-module psake

Seems reasonable enough. We simply pass along the script arguments ($args) to the invoke-psake command and everything should be fine.

OK. What happened? PowerShell did what we told it to. It called the function, invoke-psake, with an array as its first parameter rather than using the array as the list of parameters as we intended. Let’s fix that.

# Helper script for those who want to run
# psake without importing the module.
import-module .\psake.psm1
invoke-psake $args[0] $args[1]
remove-module psake

One little problem.

Note that we left out the task (“clean” previously) so that psake would use the default. Rather than using the default, invoke-psake has been passed a null argument for the task. We could fix this by detecting null arguments in invoke-psake and explicitly specifying the defaults. It’s ugly because we couldn’t use PowerShell’s syntax for specifying defaults, but it would work. Another problem is that we would need to add as many $args as we expected to receive arguments. A messy solution all around.

Fortunately PowerShell v2 has an elegant solution to this problem called the splatting operator, denoted by @. The splatting operator binds an array to the argument list of a function.

# Helper script for those who want to run
# psake without importing the module.
import-module .\psake.psm1
invoke-psake @args
remove-module psake

Note the subtle change. Rather than using $args we use @args.

Success! And it’s not just for passing arguments from one script to another. You can create arr

Note the call to “Add $addends” where PowerShell called the Add function once for every item in the array. Not what we intended. “Add @addends” using the splatting operator gave us the expected result. You can even use a hashtable to splat named parameters.

Note that the answer was 1 (e.g. 11 % 10) and not 10 (e.g. 10 % 11). The splatting operator properly bound the value 11 to the x parameter and 10 to the y parameter, just as it was in the hashtable.

The splatting operator provides us with a tremendous amount of flexibility in manipulating function and script arguments. It’s a useful tool to add to your PowerShell arsenal. Go forth and SPLAT!

New Scrum Cartoon Coming Out This Week!

[22/03/10]

Hi,

Well I am still in India and I hear your feedback that you want more cartoons.

So… withouth further ado this week, you will see a brand new one.

It focuses on a really cool Bear, and how you can do estimation and planning.

That’s it for the teaser…. Coming soon!

- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com

Introduction to the Reactive Extensions for JavaScript – jQuery Live Event Integration

[21/03/10]

So far we’ve come a long way in this series, starting with some of the basics, and then going deeper with composition with such things as the Bing Maps and Twitter Mashup, Drag and Drop, asynchronous programming among others.  One of the nicest aspects so far is the ease of integration into jQuery.  For the first release, we have Observable.FromJQueryEvent, but we didn’t quite cover live events and the integration points that we can extend.  Let’s cover that today and what is coming in a future release of the Reactive Extensions for JavaScript.

Before we get started, let’s get caught up to where we are today:

• Introduction
• Creating Observables
• Creating Observers
• jQuery Integration
• Composing Callbacks
• From Blocking to Async
• Wikipedia Lookup
• Composing Deeper
• Bing Maps and Twitter Mashup
• Drag and Drop

jQuery Live Event Integration

In an earlier post, we covered the existing jQuery event integration with the bind and unbind scenario.  This is the primary way in jQuery to attach an event handler to existing matched elements such as the following:

$("#someButton").bind("click", function() {
    $(this).attr("disabled", "disabled");
});

And then we could disable the binding such as the following:

$("#someButton").unbind("click");

And then we added a nice abstraction over this to enroll it as an observable via the Rx.Observable.FromJQueryEvent method and the extension to the jQuery fn itself of a ToObservable method.

// FromJQueryEvent
Rx.Observable.FromJQueryEvent($("#someButton"), "click"))
    .Subscribe(function(event) {
        $("#someButton").attr("disabled", "disabled");
    });    


// Or extending jQuery object
$("#someButton")
    .ToObservable("click")
    .Subscribe(function(event) {
        $("#someButton").attr("disabled", "disabled");
    });

But what about if we want to attach a handler to an event for all elements which match the selector both now and in the future?  For example, if we add elements after we have called bind on a matching selector, those will not be bound to the handler, and instead would have to rebind.  In order for us to get the behavior of attaching to all matching selectors both now and in the future, we’ll use the live function which does exactly that.  In this case, we’ll add a a click event handler to all present and future items that have the formButton class which disables the element.

$(".formButton").live("click", function() {
     $(this).attr("disabled", "disabled");
});

$("body")
    .append('<input type="button" class="formbutton" value="Click me!"/>');

Now that we’ve covered how to live bind handlers to events, what about unbinding live events?  To do that, we’ll use the die function which removes all event handlers that we’ve attached using the live function.  This example, taking from the documentation, shows a button bound to click which then live binds to the click handler of the main button.  We also bind the click handler of the unbind button which then unbinds the live handler from the main button.

function aClick() {
    $("div").show().fadeOut("slow");
}

$("#bind").click(function () {
    $("#theone").live("click", aClick)
        .text("Can Click!");
});

$("#unbind").click(function () {
    $("#theone").die("click", aClick)
        .text("Does nothing...");
});

So, how do we capture live events in the Reactive Extensions for JavaScript.  The answer is much like before when we integrated bind and unbind to the Rx.Observable.FromJQueryEvent function.  We’ll take the FromJQuery event and simply replace the calls to bind and unbind with live and die.

Rx.Observable.FromJQueryLiveEvent = function(jQueryObject, eventType, eventData) {

    return Rx.Observable.Create (function(observer) {
        var handler = function(eventObject) {
            observer.OnNext(eventObject);
        };
        jQueryObject.live(eventType, eventData, handler);
        return function() {
            jQueryObject.die(eventType, handler);
        };
    });
};

And we’ll also update the jQuery plugin to be able extend the jQuery object to have a ToLiveObservable method which will look like the following:

jQuery.fn.ToLiveObservable = function(eventType, eventData) {
    return Rx.Observable.FromJQueryLiveEvent(this, eventType, eventData);
}

Now I can rewrite the above sample which uses live and die to use the Reactive Extensions for JavaScript instead.  Instead of calling die explicitly to detach our handlers, we can call Dispose() on our subscription which underneath the covers calls the die function.

var liveEvent = null;

$("#bind")
    .ToObservable("click")
    .Subscribe(function () {
        $("#theone").text("can click...");

        liveEvent = $("#theone")
            .ToLiveObservable("click")
            .Subscribe(aClick);
        });

$("#unbind")
    .ToObservable("click")
    .Subscribe(function () {
            $("#theone").text("Does nothing...");
            
            if (liveEvent != null)
                liveEvent.Dispose();
        });

In addition to this example, we can show off the live aspect of this to show that in fact our observable is live.  This example will enlist the live click event on all paragraphs, timestamp our values, and then add a new paragraph with the associated timestamp.

$("p")
    .ToLiveObservable("click")
    .Timestamp()
    .Subscribe(function(event) {
        $("p").after("<p>Item created " + event.Timestamp + "</p>");
    });

We’re using the Timestamp method to append a timestamp to our value to keep track of time. 

Conclusion

Combining jQuery and the Reactive Extensions for JavaScript gives us even more options to deal with events.  In addition to the standard bind and unbind, we now have the ability to connect and disconnect live events as well.  That’s just one of the many things we can do with it that I’ll hopefully cover more in the near future.  So, download it, and give the team feedback!

What can I say?  I love JavaScript and very much looking forward to the upcoming JSConf 2010 here in Washington, DC where the Reactive Extensions for JavaScript will be shown in its full glory with Jeffrey Van Gogh (who you can now follow on Twitter).  For too many times, we’ve looked for the abstractions over the natural language of the web (HTML, CSS and JavaScript) and created monstrosities instead of embracing the web for what it is.  With libraries such as jQuery and indeed the Reactive Extensions for JavaScript gives us better tools for dealing with the troubled child that is DOM manipulation and especially events.

On-Site Certified ScrumMaster Course on eBay

[21/03/10]
Necessity is the mother of invention. Peter Hundermark and I are planning an exchange of experiences. He and I will co-teach a pair of CSM courses, one in Geneva, Switzerland and one in Capetown, South Africa.

Well, the course in Geneva is not really selling, so what's the plan B? Usually customers want in-house training on very short notice, but most Scrum Trainers are booked two or three months in advance. And then there are the price discussions...

So we decided to cancel the public training and offer a company training on the same date via eBay:

Certified ScrumMaster Course in Europe 15/16 April 2010

IIS 7 URL Rewriter for SEO Friendly URL’s

[20/03/10]

The other day I commented on how the IIS 7 URL Rewriter can be a neat way to transition your legacy ASP.NET Web Forms URL’s consisting of querystrings to a more RESTful, searchengine-friendly syntax. Actually, this can either be 1) a more transitory solution until you move to the new ASP.NET 4 Web Forms Routing or ASP.NET MVC, or 2) a permanent solution if you have a legacy application that you don’t plan to upgrade but want the cleaner routing.

After about 15 minutes of playing with the URL Rewriter I was pretty amazed at how quickly and easily one can clean up the inbound at outbound URL’s using it.

I created a page on my localhost that displayed products for a particular category for an e-commerce website and accepted the category as a querystring parameter as such:

http://localhost/products.aspx?category=bikinis

I wanted to map this URL for both inbound and outbound links to something cleaner, like:

http://localhost/category/bikinis

My thought was that this would be a fair amount of work, but in reality the IIS 7 URL Rewriter makes this a breeze.

Once you have installed the IIS 7 URL Rewriter you have the ability to add a rule, and in this specific case, a User-friendly URL, that is located under the header, Inbound and Outbound Rules.

Now this is where it gets slick. One enters the original URL and then chooses a more User-friendly URL from a dropdown and lets the URL Rewriter handle the rest. If, of course, you want more control you can pick another rule, but this worked perfectly for what I had in mind.

After you save the rule, your inbound routes will work correctly for any category as such:

http://localhost/category/bikinis

http://localhost/category/tshirts

http://localhost/category/hats

Also, all links to this page within the website will automagically be converted from the old querystring URL to the more searchengine-friendly URL on your behalf, no work required. Very, very slick.

If you could benefit from more searchengine-friendly URL’s, the IIS 7 URL Rewriter is worth a look. I was pretty impressed with what I could do in just 15 minutes. After a bit more understanding, I’ll definitely be showing it off at a future Sarasota Web Developer Group Meeting.

David Hayden

Rob E’s Mini-MVVM Framework @ MIX10

[20/03/10]

Rob Eisenberg’s MIX 2010 talk, “Build Your Own MVVM Framework” was terrific. If you feel modestly comfortable with MVVM, run over and get the video and the code.

Rob may be best known for his Caliburn WPF/Silverlight Presentation Development Framework. That’s a hefty body of work and if the word “framework” sends an unpleasant shiver down your spine … relax yourself.

The “framework” demonstrated at MIX is roughly 500 lines (says Rob … I haven’t checked yet <grin/>). It’s based on Caliburn but stripped to essentials that Rob covered in an easy-to-follow, leisurely, one hour code-walk.

Highlights:

• Simple MVVM
  • "VM first" in the sense that VM is in the driver's seat.
  • No impediment to "View first" in the sense of view-design drives VM-design.
• Simple naming conventions eliminate tedious code and XAML
• Configuration at-the-ready when conventions fail
• No code-behind … and didn’t miss it
• No behaviors … and didn’t miss them (not that they’d be bad)
• No XAML data binding; debuggable bindings created at runtime
• No drag-and-drop binding … and didn’t miss it
• No ICommand implementations and no event handlers
• No files over 150 lines (as I remember)
• Cool co-routines for programming a sequence of sync and async tasks; no call backs in the ViewModel
• Screen Conductor pattern in play

All that in one hour.

The “co-routine” trick alone is worth your time. You almost get F# “bang” syntax in C#.

It could get more complicated in your app … and you’d have Caliburn. But it might not  … and you’d be living large with dead-simple, DRY code.

One of the best sessions ever.

If only we could teach Rob to emote. The guy is passionate on the subject but you might miss it behind that mono-tone voice of his. A Jim Carrey he is not. You want entertainment? Look elsewhere. You want substance … tune in.

He got a big ovation, by-the-by, so it ain’t just me who liked it.

TDD: Expressive test names

[20/03/10]

Towards the end of a post I wrote just over a year ago I suggested that I wasn't really bothered about test names anymore because I could learn what I wanted from reading the test body.

Recently, however, I've come across several tests that I wrote previously which were testing the wrong thing and had such generic test names that it wasn't obvious that it was happening.

The tests in question were around code which partially clones an object but doesn't copy some fields for various reasons.

Instead of documenting these reasons I had written tests with names like this:

[Test]
public void ShouldCloneFooCorrectly() { }

[Test]
public void ShouldSetupFooCorrectly() { }

When we realised that the code wasn't working correctly, which didn't happen until QA testing, these test names were really useless because they didn't express the intent of what we were trying to test at all.

Damian and i spent some time writing more fine grained tests which described why the code was written the way it was.

We also changed the name of the test fixture to be more descriptive as well:

[TestFixture]
public class WhenCloningFooTests
{
	[Test]
	public void ShouldNotCloneIdBecauseWeWantANewOneAssignedInTheDatabase() { }
 
	[Test]
	public void ShouldNotCopyCompletedFlagBecauseWeWantTheFooCompletionJobToPickItUp() { 	
}

It seems to me that these new tests names are more useful as specifications of the system behaviour although we didn't go as far as you can with some frameworks where you can create base classes and separate methods to describe the different parts of a test.

Despite that I think naming tests in this way can be quite useful so I'm going to try and write more of my tests like this.

Of course it's still possible to test the wrong thing even if you are using more expressive names but I think it will make it less likely.

MVVM, Josh Smith’s Way

[19/03/10]

I’ve long admired Josh Smith’s work. He’s one of the best explainers on the web and he – together with Karl Shifflett and Andrew Smith - gave us Mole, the superb WPF Visual Studio debugger visualizer.

I heard recently that he’d published an e-book on Model-View-ViewModel (MVVM). I met him for the first time at the Microsoft MVP Summit last week and he graciously handed me a printed copy. I devoured it on the plane home and spent the next day playing with the code and preparing this review.

It’s called “Advanced MVVM” and you can buy a printed copy for $20 or get it for $15 on the Kindle. The companion code is freely available at AdvancedMvvm.com .

$15 bucks for a 52 page “book”? It’s more of an extended essay to be honest … an essay with code. After spending some pleasurable hours with both book and code I thought “where do you get that kind of entertainment / self-reflection for $15?” I have a surfeit of 600 page sleepers lounging on my bookshelf at home; paid more then $50 for each and hardly cracked them. Should we pay by the pound? So I’m over it. I don’t mind paying for the hours Josh poured in and the fun I got out. Set your expectations appropriately and you’ll feel fine.

---- 19 March 2010 Note ---

Ok, it’s been a month or so since I wrote this. Life happens while you’re making plans. I intended to be among the first to comment on it. I’m late to that party (although I have deliberately NOT looked at what others may have said) so I’m not sure if it’s still timely. I also shared it with Josh last week to see if I had missed something and get his feedback, particularly in light of my critical remarks.

He encouraged me to publish it even at this late date. I hope he’ll repost here some of his responses to the points I raised.

----------------------------------

MVVM has spooked a lot of developers. There’s more than a whiff of astronaut architecture about it. There have to be at least 20 MVVM frameworks and no end of contentious arguments to confound and distress you. No wonder so many are put off.

MVVM in a Nutshell

In fact MVVM is fundamentally a simple idea. It starts with the realization that your application is an intractable mess in part because you dumped all of your UI logic into the code-behind … with the help of Microsoft tools. You discover the wisdom of pulling much of that logic out into a companion class (and some helpers) leaving the view class to concentrate on looking pretty and capturing user gestures. The view and its companion must talk; you can structure their conversation according to a variety of familiar patterns. Model-View-ViewModel is one such pattern.

The predominance of automated binding is the hallmark of MVVM. You bind a View’s textbox to a string-providing property of the ViewModel so that a user’s changes in the textbox flow to the property and so that programmatic changes to the ViewModel property flow back to the textbox. You bind View events (e.g., button click) to event handlers in the ViewModel enabling user gestures to be conveyed to the ViewModel.

You could write your own bindings by hand, pushing and pulling data and events with custom code. That’s a lot of work. The XAML-based client technologies (WPF and Silverlight) provide a binding framework that requires little to no custom coding. In most cases you can “connect the dots” declaratively and it just works.

Now the View concentrates on appearance and the ViewModel feeds the view. This separation is both clarifying and liberating. You can start looking at that ViewModel to figure out what it should do and how it should do it without also worrying about the visuals. The subsequent examination of ViewModel’s more limited responsibilities sets you on a more sustainable course. At least this has been my experience … and that of the hundreds (thousands?) of other developers who’ve adopted this pattern.

Now you’ll note that I said it “sets you on course”; I did not say it delivers you to the promised land. There are details to work out. If the View looks to the ViewModel for data, where does the ViewModel get that data? Are we talking about data values alone or the business rules that surround that data, rules about data validity, integrity, security, and persistence?

Many of us draw a circle around these concerns and call that circle “the Model”, the third element in the MVVM triad. Our guiding intuition is this: “the persistent data are definitely in the model and if the rules about data are true for this and every possible UI, the rules belong in the model as well.”

If the last name is required, it is required everywhere; that’s a model rule. If gold customers can select from several thank-you gifts, that sounds like UI logic to me … and belongs in the ViewModel. The specifics have to be worked out.

Back To Josh

At this point the discussion risks slipping into theory and theater. We could run to the white board, scribble madly, and count angels on pins without writing a line of code. I love doing that.

Josh has taken another direction which is likely to be both more popular and more effective. He briefly presents his take on MVVM in clear, accessible prose … and then makes it tangible with an extended exploration of a meaty sample application. I’ve read plenty of pattern papers; I don’t remember any that were so thorough … and entertaining … in their examples.

For style and substance this is a remarkable achievement. I truly hope that Josh’s book is widely read because I think it has a better chance of helping WPF and Silverlight developers feel comfortable about MVVM than anything else I’ve seen.

I’m a little worried that some will fear the word “Advanced” in the title. The term “MVVM” is forbidding enough and many folks are still looking for the introduction. I think this book is the introduction they really need.

In what sense is it “advanced”? It’s far from the last word on the subject. It won’t settle any arguments (least of all mine). But it does rise above the introductory level in two important respects.

First, it considers the implications of multiple, cooperating MVVM instances. Most MVVM articles present a single MVVM-triad: a single View and its companion ViewModel and Model.

No application needs a single MVVM triad. If you have a one-screen application, don’t use MVVM; it’s overkill. MVVM is for multi-screen applications consisting of multiple MVVM triads which spring to life somehow and somehow interoperate.

Second, as I noted earlier, Josh doesn’t just talk about the pattern. Most of the pages describe the accompanying game, BubbleBurst, which is implemented in MVVM style. Instead of paeans to principles and their wondrous benefits, you see MVVM in action, warts and all.

BubbleBurst is “advanced” enough to both introduce MVVM and reveal important implementation challenges of multi-MVVM applications. Yet it’s simple enough to be easily understood in the pages of a book or in a few hours spent trolling the code. It’s also fun to play.

Proceed with Caution

I’m about to begin my critical remarks. Before I do, I want to reemphasize my enthusiasm for what Josh has accomplished. This book is a wonderful place to begin your MVVM journey and I found it to be an enjoyable and insightful read. So, hell-yes, I’m recommending it.

On the other hand, it would be a shame if developers stopped their education here. Important elements of the story are missing and many recommendations are seriously misguided in my view. Readers should take Josh seriously but, once they are comfortable with the pattern, they should become aware of starkly contrasting perspectives as well.

Critical Omissions

Four vital topics are neither covered nor illustrated in the code:

• Testing
• Model (the first ‘M’ in MVVM)
• Dependency Injection
• Event Aggregation

Testing

Josh asks “What is the point of having ViewModels?” First among his reasons: “the ability to easily write unit and integration tests for the functionality of the user interface without having to get into the messy world of writing tests for live UIs.”

That’s the last we hear of testing. There is not a single test in the code base. If testing is as important as he says, I’d expect a thorough treatment starting with building a test regimen and showing, by example, how to write good tests. Instead, we get lip service.

I don’t think testability is the only value of MVVM. I couldn’t recommend it for this reason alone. MVVM is a significant architectural investment that introduces complexity. I wouldn’t incur that complexity cost merely to make my UI testable. I’d look for a less onerous route. Fortunately, I think it has other benefits such as clean separation of concerns, improved readability, and easier debugging (try break-pointing XAML!).

But testability is both a motivation for and a by-product of MVVM style and it should have been covered thoroughly in an “advanced” treatise on MVVM.

Moreover, the design would have benefitted greatly from attempts to test it. Many lines of view code-behind are both untestable and harder to follow than they should be. I see early signs of the spaghetti code that afflicts more complex and mature applications … a drum I’ll beat furiously later in this review.

At almost 300 lines, the BubbleMatrixViewModel begs to be tested both for quality and to reveal the expectations latent in its 20+ public and internal members.

The Missing Model

The pattern is called Model-View-ViewModel. Josh’s Model is nowhere to be found. Model and ViewModel are combined and it’s not clear to me how one would disambiguate them.

The absence of Model isn’t blatantly obvious in a simple game like BubbleBurst. The game doesn’t to retrieve or save objects to a persistent store. We aren’t expecting much in the way of business model logic either; there’s nothing of interest to validate or secure. So the lack of a model is not a deep fault of this particular application. Indeed, it’s a convenient way to concentrate our attention on the central issues for most students of MVVM:

• What code belongs in View and what code in ViewModel?
• How do View and ViewModel interact?
• How do you instantiate Views and ViewModels?

Nonetheless, we can’t pretend to provide a comprehensive guide to MVVP without talking about the Model and how it interacts with ViewModel and (to a lesser extent) View. A business application will demand a clear delineation of responsibilities and equally clear communication paths.

I’m not letting BubbleBurst off the hook either. I felt on several occasions that some ViewModels were heavier and more complicated than they should be because an inchoate game model was not independently defined.

Dependency Injection

I appreciate that Dependency Injection frightens many developers. You can discover MVVM without learning about Dependency Injection. Josh can kind of get away without it as long as he doesn’t test his ViewModels and doesn’t have to think about the services required to manage a persistent model.

But I feel you can’t call this “Advanced MVVM” … or even “Intermediate MVVM” … without introducing DI at some point. In Josh’s application, every View and every ViewModel class is known to and instantiated by some other View or ViewModel class. That won’t fly in real-world applications which have Views and ViewModels that are ignorant of each other.

The constructor of the BubbleMatrixViewModel instantiates three concrete bubble components: BubblesTaskManager, BubbleFactory, and BubbleGroup (twice) before making heavy use of them.  That’s a lot of dependencies that would make this ViewModel brittle and especially difficult to test.

Taking hard dependencies means Josh can freely assume that ViewModels will always have parameterless constructors and can always be instantiated in XAML, as he often does here. Someone new to MVVM might think this is the norm. It is not.

Josh himself alludes to DI as one of the avenues opened by the MVVM pattern: “[MVVM] means that you can use frameworks like MEF to dynamically compose your ViewModels, to easily support plug-in architectures …”. That’s the last we hear of MEF or dynamic VM composition.

Again, I think we can ignore DI in an introduction to MVVM; we cannot ignore it in an advanced lesson on MVVM.

Event Aggregation: communicating with the unknown

All of Josh’s MVVM triads are statically determined. Their relationships to each other are fixed and well known.

I was surprised to see a ViewModel for one view hold a reference to a ViewModel of a subordinate view. That’s not how I do it; my general rule is that MVVM triads do not hold references to each other. I concede that the rule makes it difficult to organize cross-triad communication. Josh’s approach is simple and elegant … when available.

In real-world business applications, the MVVM triads often can’t know about each other. They are often defined in separate modules without mutual references. Views appear and disappear dynamically. Direct communication is frequently impossible.

That’s why so many so-called MVVM frameworks include some kind of messaging or Event Aggregation infrastructure. You don’t need them to understand MVVM triads in isolation. But you never see an application with a single MVVM triad and you rarely find an MVVM application with statically determined, session-permanent views. No “advanced” treatment of MVVM can neglect Event Aggregation.

View First or ViewModel First?

Here’s an incendiary topic Josh leaves untouched.

I see two ways to ask this question:

• Do I design the View first or the ViewModel first?
• Do I instantiate the View first or the ViewModel first (or does something else instantiate and wed them)?

The answer to both questions need not be the same. For example, you could decide to design the ViewModel first and let the View instantiate that VM at runtime. This is plausibly the approach advocated in BubbleBurst although Josh never talks about it.

Again, it’s important that readers new to MVVM learn that Josh’s way is not the only way.

View and ViewModel Design

In my experience there is a “dialog” between View and ViewModel design. The VM exists to serve a view even as it strives for independence from any particular concrete view. A VM is useless if  there is no view that will work with it; clearly the VM developer must heed the imprecations of the View developer.

On the other hand, in business applications the application’s imperatives – what the view must do to satisfy business requirements – are the province of the programmer and are best articulated through the capabilities of the ViewModel.

Therein lies the necessary tension between View and ViewModel design. As a developer my allegiance is with the ViewModel (“the application should do something worthwhile”) but it would be silly to defend that allegiance at the expense of the View (“a good UX is essential to making an application easy to learn and to use”).

I’d have liked to see this tension at least acknowledged and perhaps explored.

Who begets Whom?

Runtime construction is a question apart from the matter of who drives the design. WPF and Silverlight tooling push you toward “View First” construction in which the View instantiates the ViewModel. You’ll often see the View’s DataContext set by a ViewModel instantiated in the XAML as shown here:

  <UserControl.DataContext>
     <viewModel:BubbleBurstViewModel />
  </UserControl.DataContext>

Contrast this with the ViewModel first, code-based approach (not seen in BubbleBurst) in which the ViewModel is assigned to the View’s DataContext as follows:

 view.DataContext = viewModel;

The View First approach assumes that the ViewModel can be created via a default, parameterless constructor. That’s fine for BubbleBurst but wholly unrealistic in business applications whose ViewModels have dependencies (e.g., on the domain model).

Neither WPF nor Silverlight XAML support the dependency injection mechanisms that many of us prefer. I wish Josh had talked about this and perhaps discussed the interesting attempts to use MEF dependency injection (via properties rather than constructor arguments)

I’m not trying to settle these questions. I am saying these questions could have been called out in an “advanced” book on MVVM patterns.

What Belongs In Code-Behind?

Do we allow or prohibit code-behind? That’s a fist-fight topic. Josh looks for a Goldilocks solution, suggesting the amount of code-behind is just right if confined to “logic scoped to the view”.

Such guidance is far too loose in my opinion. It’s not effective guidance at all.

We choose presentation separation patterns in part because we want to minimize testing of the view. We should test any custom logic we write – no matter how it is scoped. The poverty of our testing tools means that, in practice, we will not test the code in the view. Therefore, any code in the code-behind is suspect.

I am open to some code in the code-behind; the “InitializeComponent” method is inescapable. I’ll accept a minimum of “switch board” code in the code behind; direct wiring to a ViewModel member is ok in small doses.

I draw the line at decision logic. I smell a rat when I see a conditional statement of any kind. That’s where bugs breed. Conditional logic is code we should be testing.

I much prefer this rule: “No conditional logic in the code-behind”.

That’s unambiguous. We don’t have to wonder what “scope of the view” means. If there’s an “if” or a “switch” statement, something is wrong. You can detect a violation with automation or visual inspection. It’s a rule that’s easy to follow and pretty easy to abide by … when you know how.

What happens when you don’t follow this rule? You’re lured into the kind of dodgy code that … well we see in the innocent seeming BubbleMatrixView.xaml.cs.

In fact, far from being “best practices”, I’d say that the View code in BubbleBurst represents some of the worst practices.

Look at the HandleMatrixDimensionsAvailable method. This event handler is wired to a UI element in the BubbleBurstView. Unfortunately, the UI element happens to be in a different view, the BubbleMatrixView! One view’s code-behind is wired to members of another view; that’s the road to perdition. That would never pass my review.

I wanted to clean it up immediately. I tried to find the intention behind this practice. Usually I look to the name of a method to discover its purpose. Unfortunately the handler is named for the moment when it is called (“Matrix dimensions available”) rather than for what it does. That’s conventional naming for event handlers but not terribly informative. Unless a handler is brain-dead-simple, I have it delegate immediately to methods with meaningful names. The handler tells me when something happens; the inner method tells me what will be done.

Had Josh adopted my suggestion, he’d have realized that his handler has multiple responsibilities:

• wires the outer window’s keydown event
• picks up the dimensions of the related view’s grid
• starts the game

That’s too much work for code-behind in my book.

When we strive to apply the “no conditional logic in the code-behind” rule, we discover other design problems.

It appears that Undo logic is distributed between two ViewModels. One of them, the BubbleBurstViewModel, determines if undo is possible while the second, BubbleMatrixViewModel performs the undo. Probe further and we find that even the BubbleBurstViewModel test for undo-ability is delegated back to the BubbleMatrixViewModel. The ping-ponging among Views and ViewModels is confusing; it doesn’t smell right.

All the signs suggest the real action is in BubbleMatrixView and its ViewModel.

BubbleMatrixView.xaml is short and sweet.The code-behind in BubbleMatrixView.xaml.cs is another story. Five Region tags sound the alarm. You shouldn’t need region tags in code-behind. Here they barely disguise the complexity of 145 lines of code-behind. That can’t be right.

MicroControllers: BubblesTaskPresenter Example

I was able to refactor the 53 lines dedicated to animating bubble tasks. Most of them went to a BubblesTaskPresenter class, a component Jeremy Miller calls the “MicroController”.

Every MVVM developer should become familiar with the “MicroController” approach.

A “MicroController” performs a narrow UI task on behalf of a view. We usually write one to encapsulate UI logic that is reused across multiple views. That’s not the case here; the application is too small.

We also write MicroControllers to encapsulate UI-specific functionality in a UI-agnostic wrapper. They make it easy for non-UI components, such as ViewModels, to invoke the UI-specific behavior we find in Views. That’s what we need here.

I noticed that the ViewModel holds a TaskManager which raises a PendingTasksAvailable event when there are bubble display tasks. This sets off a sequence of calls between View and ViewModel which collectively “process tasks” queued up by the ViewModel.

Josh’s original code forwarded the event to the View’s code-behind. That code-behind then extracted the VM’s TaskManager and called into it. 53 lines of code-behind are dedicated to this entire process.

After my revision, the view merely provides the ViewModel with a configured MicroController, here called a “BubblesTaskPresenter”:

 _bubbleMatrix.BubblesTaskPresenter = new BubblesTaskPresenter(_bubbleCanvas);

This is what switchboard code should look like. I’d like to get rid of the instantiation but at least there is a bare minimum of logic and no conditionals.

The ViewModel receives the concrete presenter in the guise of a UI-agnostic interface, IBubblesTaskPresenter and wires itself to the presenter’s events.

    public IBubblesTaskPresenter BubblesTaskPresenter {
      get { return _bubblesTaskPresenter;}
      set {
        _bubblesTaskPresenter = value;
        _bubblesTaskPresenter.Completed += delegate { ProcessTasks(); };
        TaskManager.PendingTasksAvailable += delegate { ProcessTasks(); };
      }
    }

    private void ProcessTasks() {
      var task = TaskManager.GetPendingTask();
      BubblesTaskPresenter.PresentTask(task);
    }

IBubblesTaskPresenter uses simple .NET types and looks like this:

  /// <summary> 
  /// Interface for a presenter of <see cref="BubblesTask"/>
  /// </summary>   
  public interface IBubblesTaskPresenter {
     void PresentTask(BubblesTask task);
     event EventHandler Completed;
 }

Where did the 53 lines of code-behind go? Into the BubblesTaskPresenter.

What has been gained? Did I just hide the pea under another untestable cup called a “presenter”? Is this merely an academic exercise?

I don’t think so. True, the presenter is dependent upon WPF and upon BubbleCanvas in particular. But it could be tested with a faked canvas and a faked factory. Testing aside, it’s small and focused; it’s easy to see what it does and how it works. It won’t get lost amidst the other motions of the BubbleMatrixView. We might someday use it in another view that presented BubblesTasks.

The BubbleMatrixViewModel has grown a few lines but remains readable and testable; its imported IBubblesTaskPresenter is easy to fake.

The ViewModel no longer exposes the TaskManager. That’s a good thing because the TaskManager is pretty complex piece of machinery with a rich API. We don’t want the View or BubblesTaskPresenter to know about it.

And the View is 53 lines lighter, reducing the anxiety we might justifiably feel if we handed it over to a non-programming designer for styling.

Homework Assignment: if you’re playing along and are looking toward your own application design, you might want to linger over the BubblesTaskPresenter. It is specific to bubbles right now … which is appropriate in the absence of forces that would drive us to generalization.

But you can encapsulate storyboard animations in much this way to both determine state changes within the ViewModel and externalize the animations in “View-space” where they belong. Josh is spot-on when he insists on this separation. The MicroController “presenter” approach is one way to achieve that separation without polluting the code-behind.

Aside: my first presenter was more abstract and general purpose. My generalization was premature. Generalization made the code more complex than it needed to be in this application. I un-factored it to the current version that knows about BubbleCanvas and BubblesTaskStoryboardFactory.

Views Shouldn’t Talk To Views

After clearing out the 53 lines, I was able to focus on what’s left.

I was deeply troubled by the properties of BubbleMatrixView that are exposed to and consumed by the BubbleBurstView code-behind. That can’t be right. Views shouldn’t need custom properties.

If you have to expose a custom view member, you should do so through a view interface. We don’t want any code – View or ViewModel – depending upon a concrete view class. That’s asking for trouble and flies in the face of the testability which justifies MVVM.

It’s also completely unnecessary in this application. As noted earlier the event loop from inner BubbleMatrixView to outer BubbleBurstView leads back around to BubbleMatrixView’s ViewModel. We can cut all that nonsense out and simply update the BubbleMatrixViewModel directly in the code-behind … without any conditional logic.

I refactored as follows:

• Removed 30 lines from BubbleBurstView code-behind
• Added “StartTheGame” to BubbleMatrixViewModel; it combines the functions of setting the dimensions (now private) and starting a new game.
• Removed 61 lines from BubbleMatrixView code-behind which now calls StartTheGame when the canvas is loaded. Region tags are gone.

The BubbleMatrixView code-behind is now a trim 30 lines with no conditionals, down from 145 (80% reduction). Of the 30, exactly 5 of them do work.

My cleanup involved eliminating several null checks. They never did anything useful. First, the variables could not be null in practice. Second, even if they were (e.g., someone broke the xaml), the application would not have functioned anyway. I don’t think a blank screen is superior to an exception. The null checks were about as helpful as empty catch blocks.

Tidy-up BubbleBurstView Code-Behind

BubbleBurstView’s code-behind had one remaining “if” and some other code that I felt didn’t belong there.

Key monitoring logic contained an “if” statement. At first it seemed like key monitoring was a candidate for another MicroController. But there is only one key to handle, the key for Undo. That wasn’t worth the overhead of another MicroController component. Instead I decided to enrich the BubbleBurstViewModel with an Undo method whose signature is:

  public bool TryUndo(bool shouldTry) // returns True if undid

The code-behind calculates whether the key presses amount to an undo request. The call is:

  e.Handled |= _bubbleBurst.TryUndo(isUndoKey);

I don’t like the isUndoKey calculation but I’ll leave it for another day.

My final bug-a-boo is the LoadBubbleViewResources method which instantiates a ResourceDictionary and plugs it into the application-level resources.

I expected this to be loaded by the App.xaml itself but I suspect Josh wants to simulate the notion that independent assemblies have their own resources. While the “Bubble.View” assembly is not independent – the App.xaml has access to it through its host assembly’s references –, I’ll play along.

In any case, the view’s code-behind shouldn’t know the details of ResourceDictionary construction and App.Resources update. Time for a MicroController: “BubbleViewResourceLoader” which we can invoke from within the code-behind’s constructor for now. It still stinks but it stinks less.

The code-behind now stands at 41 lines, down from the original 86; only 9 of them do work.

Picky, Picky

I’m a restless complainer. I’ve got a few more bones to pick having nothing to do with MVVM.

Page numbers! You may have noticed that my citations lacked page numbers. That’s because there aren’t any in the printed document I’m reading.

The abundance of Region tags annoys me. Hey, I use them too, especially in pedagogical code where I want to unveil new ideas didactically in the course of a presentation.

I appreciate that they seem to organize the code into nice buckets: “constructors”, “methods”, “fields”. But lately I’ve come to believe that they’re more of a code smell.

If the class is short – as it should be – they interfere with my ability to read and grasp the class at a glance. If the class is long, they suggest that my class implements too many distinct concerns and I’m struggling – vainly – to keep them organized. These concerns would be better delegated to supporting classes. I suspect that automated testing would make this defect more obvious.

I’m not thrilled with the data triggers. Data triggers are not available to Silverlight programmers probably for good reason. The Visual State Manager is the preferred choice for both WPF and Silverlight.

A particularly egregious data trigger can be found in BubbleBurstView.xaml where the GameOverView is collapsed when the BubbleBurstViewModel’s GameOverViewModel is null. Could there be a more obscure way to signal that a modal dialog should be hidden? I suspect a bound IsGameOver property would be both simpler and more obvious.

Where’s The Code?

Josh’s original source is at AdvancedMvvm.com . I’ve temporarily posted my refactored version on my site. I’m not promising it will stay there- this is Josh’s code and I’ll do whatever he wants me to do with it (including burn it) – but it’s there now and I’ll let you know if I move it.

Wrap Up

I have high hopes for the conversation Josh has started with this book.

I see it as one place to begin your study of MVVM rather than as the definitive work on the subject. Some of the practices I find dubious and there are serious omissions.

But I gave it this much attention because it deserves it. It’s a fine piece of writing, a carefully considered example, and a push in the right direction. Josh speaks to a broad audience with an authentic voice they understand and respect. He has my respect as well.

It’s well worth the $15 bucks on the Kindle.

Enjoy!

p.s.: Cross-posted to my other blog, "Never In Doubt"

DevTeach Toronto 2010 Wrap-Up

[19/03/10]

Another year, another DevTeach. A big thank you to everyone involved. To the organizers, Jean-Rene Roy and Maryse Dubois, thank you for continuing to support and encourage the Canadian developer community. To my fellow Tech Chairs, for helping select an awesome array of both local and international talent to present. To my fellow speakers, for giving some fantastic talks. To all the attendees, for their eager participation, helpful comments, and continued encouragement. To old friends and new whom I spent catching up with in the unofficial speakers lounge, at dinner, and around drinks. There is always something new and fun at DevTeach and this year was no exception. Here are the slides decks and code for those interested:

Convention-over-Configuration in a Web World (pptx | code)

Convention-over-Configuration in an Agile World (pptx | code)

Agile Development with IoC and ORM (pptx | code)

If anyone has any questions, comments, or issues with the slidedecks or code, don’t hestitate to leave me a comment.

Archives

[19/03/10]  - ASP.NET Performance Framework

[19/03/10]  - Introduction to the Reactive Extensions for JavaScript – Drag and Drop

[18/03/10]  - Essential and accidental complexity

[18/03/10]  - Organizational Barriers and Impediments to Big Scrum Implementations

[18/03/10]  - Architecture and Design Evolution

[18/03/10]  - Positive Psychology and Team Performance

[18/03/10]  - Orlando Scrum Gathering blog/link below

[18/03/10]  - Your chance to heckle me on Ignite your Coding tomorrow

[17/03/10]  - The Reactive Extensions for JavaScript Released

[17/03/10]  - What is Scrum?

• Scrum master
• Scrum tools
• Scrum sprints
• Ken Schwaber scrum
• Formation scrum

• Agile software developement scrum
• Scrum backlog
• Scrum impediment
• sprint backlog
• Product BackLog

• Backlog template
• Scrum developement
• Scrum methodologie
• Scrum certification
• Scrum meeting

• Scrum tools
• Scrum definition
• Agile
• Scrum project management
• Agile project management

• About Us
• Contact Us
• Privacy Policy
• Terms & Conditions