Let's say you're a developer -- and you probably are if you're reading this.  How do you know if you have a generally sunny, optimistic set of mind or a gloomy, pessimistic attitude?  It's very simple.  You know how you constantly look at 6 month old code and see a better way to rewrite the code?  An optimist rewrites that code and says "damn, the new code is so much cleaner!"  The pessimist rewrites the old code and says "damn, that old code sure was a mess."

And if you never find any thing wrong with your 6 month old code?  You sir are either severely lacking in retrospection and/or you might very well be unconsciously incompetent.

In an interesting turn of events, I've been invited to blog here! Having followed CodeBetter for a number of years, I'm extremely honoured and excited to be sharing my thoughts, opinions and discussion points here. 

My aim is to share my learning experience and journey on becoming a better software developer – or even a software craftsman with readers hopefully pointing me in the right direction when I go astray... 

Before CodeBetter, I've been blogging at Blog.BenHall.me.uk. My plan is to keep this blog alive with personal items such as slides, upcoming presentations and topics unrelated to CodeBetter. Alongside my blog, I was the co-author of Testing ASP.net Web Applications, released last November covering various different issues associated with ASP.net from TDD to manual testing to load testing. Using this as a foundation, I'm planning to cover more topics related to the subject together with my current work at 7digital.com where I am a developer.

If you want to know what I'm up-to before (or even if) I write about it here, then follow me on Twitter and on GitHub.

We’ve covered a bit of ground already in this series on the Reactive Extensions for JavaScript (RxJS) from the basic information, creating observers and observables, jQuery integration, composing asynchronous methods with callbacks and in the last post, talking about turning blocking calls into asynchronous calls.  Now that we have some more fundamental building blocks, let’s see what else we can do with it.  Before I move into FlapJax examples translated to the Reactive Extensions for JavaScript, I want to first visit a basic autocomplete/lookup scenario in which we can query a data source as we type, as such sites as Bing, Google, Wikipedia and others do.  In this example, we’ll use Wikipedia as the backend source for doing our autocomplete.

Also, if you’re at Mix this year, you’ll notice that Erik Meijer is giving a talk on the Reactive Extensions for JavaScript. I highly recommend that you go to this session, especially if you’ve been interested in this series.  Prepare for some pretty slick demos to show off the functionality of the library. 

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 Asynchronous

Building a Lookup with Wikipedia

Our overall goal is to show how an autocomplete/lookup scenario might work using the Reactive Extensions for JavaScript.  I’ll show the basic mechanisms of querying the data set and returning the data, but the actual integration into a div could be up to you.  For simplicity sake, I’ll just stick the results into an unordered list for display purposes.  First, we need to familiarize ourselves with the Wikipedia API.  In order for us to do a basic open search, we can use the following URL where the <term> is replaced with your query.

http://en.wikipedia.org/w/api.php?action=opensearch&search=<term>&format=json

For example, I can search for Matthew using the Wikipedia API, and in JSON format, it should look like the following, where it returns a string array with the first element being my query, and the second element being an array of my search results.

["Matthew",["Matthew the Evangelist",
            "Matthew C. Perry",
            "Matthew Broderick",
            "Matthew Flinders",
            "Matthew McConaughey",
            "Matthew Arnold",
            "Matthew Perry",
            "Matthew Hayden",
            "Matthew Sweet",
            "Matthew Fox (actor)"]]

Knowing this, we could create an AJAX call to the API based upon a term and then only select the second element, our results, as our observable sequence.  In order to enable AJAX functionality, the Reactive Extensions for JavaScript comes with the XmlHttpRequest method which has two overloads, one that takes a simple string URL and that takes an XmlHttpRequestDetails which contains details about the request.  Let’s look at the signatures of the XmlHttpRequest methods:

function XmlHttpRequest(
    details); // An XmlHttpRequest details instance
    
function XmlHttpRequest(
    url);    // The URL of the request

And to give you an idea XmlHttpRequestDetails looks like, let’s look at the properties exposed on this class which include the headers, method, user, password and URL.

function XmlHttpRequestDetails() {
    this.Headers  // Adds custom HTTP headers to the request
    this.Method   // Specifies method GET, POST, HEAD
    this.Password // Password for authentication
    this.Url      // Url for request
    this.User     // User for request
};

Now, let’s function called searchWikipedia that takes our search term and creates an XmlHttpRequest to Wikipedia and then projects the proper results.  To do this, we’ll call the Rx.Observable.XmlHttpRequest method and then call Select to turn the eval the JSON response and select the second item in the array, our array of results.

function searchWikipedia(term) {
    var url = "http://en.wikipedia.org/w/api.php"+
        "?action=opensearch&search="+term+"&format=json";
    
    return Rx.Observable.XmlHttpRequest(url)
        .Select(function(result) {
            var response = eval(result.responseText);
            if(response.length == 2) return response[1];
            else return [];
        });
}

Now, let’s hook it all together, so that when a key goes up, that is to say enters a value, then we’ll trigger a search to Wikipedia.  Our simple search screen looks nothing more than a simple input for our text value and a UL for our results, and an area for errors should one occur.

<body>
    <input id="searchInput" size="100" type="text" />
    <ul id="results" />
    <p id="error" />
</body>

Once the document loads, we want the ability to track the keyup event of our searchInput and then display the results (if any) in our results, else populate the error.  As per usual, we’ll wrap this functionality into our document.ready function.

$(document).ready(function() {
    // Code goes here
});

The next part is the fun part.  We need to take our searchInput and listen to the keyup event. 

var searcher = $("#searchInput")
    .ToObservable("keyup")

One the key event fires, we need to project that it happened and return the current searchInput value which contains our search term. 

    .Select(function(_) {
        return $("#searchInput").val(); })

Then, we’ll need to slow down the response to the request to Wikipedia so that we’re not constantly bombarding their server, but instead wait until an interval before firing and ignore all that happen during that interval.  To do that, we’ll make use of the Throttle function:

function Throttle(
    dueTime); // Ignores values which are followed by another
              // value before the due time

In this case, we’ll use 250 milliseconds as our interval time.

    .Throttle(250)

Next, we’ll take the observable and project our search term to return our searchWikipedia observable.  What this returns to us in C# parlance is an IObservable<IObservable<string>>. 

    .Select(function(term) {
        return createSearchRequest(term); })

We’ll need to flatten this, but only take the first value since it’s a single request.  To do that, we’ll need to use the Switch function which transforms an observable sequence of observable sequences into an observable sequence producing values only from the most recent observable sequence.

    .Switch();

Below is the complete code to create the observable which searches Wikipedia and then returns an array of values as the result.

var searcher = $("#searchInput")
    .ToObservable("keyup")
    .Select(function(_) {
        return $("#searchInput").val(); })
    .Throttle(250)
    .Select(function(term) {
        return searchWikipedia(term); })
    .Switch();

Now we can populate the unordered list by subscribing to our searcher.  As search result comes back, we want to clear the results, and then iterate through our array to add an item to the list.  Also, we can handle errors by simply pushing the exception value to another area for display should one occur.

searcher
    .Subscribe(
        function(data) {
            $("#results").empty();
            $.each(data, function(_, value) {
                $("#results").append("<li>"+value+"</li>");
            });
        },
        function(error) {
            $("#error").html(error);
        });

Let’s take a look at this in action.  I’ll search for Matt to start which returns the following results.

When I enter the next key, an “h”, my results refresh with the following.

As each letter comes along, then our results refresh based upon Wikipedia thinks we might be looking for.  And there you have it, a simple Wikipedia autocomplete autocomplete/lookup scenario as accomplished with the Reactive Extensions for JavaScript.

Conclusion

Through the use of the Reactive Extensions for JavaScript, we’re able to perform AJAX calls and then compose it together with our key-up to create a dictionary lookup/autocomplete scenario. 

This of course is only scratching the surface of what capabilities this library has and there is much more yet left to cover.  The question you’re probably asking now is where can I get it?  Well, for that you’ll have to stay tuned to Erik Meijer and his Reactive Extensions for JavaScript session at Mix on Wednesday.

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.

I recently came across node.js via a blog post by Paul Gross and I've been playing around with it a bit over the weekend trying to hook up some code to call through to the Twitter API and then return the tweets on my friend timeline.

node.js gives us event driven I/O using JavaScript running server side on top of Google's V8 JavaScript engine.

Simon Willison has part of a presentation on slideshare where he describes the difference between the typical thread per request approach and the event based approach to dealing with web requests using the metaphor of bunnies. He also has a blog post where he describes this is more detail.

Another resource I found useful is a video from jsconf.eu where the creator of node.js, Ryan Dahl, explains the philosophy behind event driven I/O and gives several examples using node.js.

These are some of my thoughts so far:

• I'm not used to have so many callbacks spread all around the code and I'm still getting used to the idea that they aren't executed until the event actually happens!

  I often find myself looking at a piece of code and not understanding how it can possibly work because I'm assuming that the function passed in is executed immediately when in fact it isn't.

• If you make a web request the response comes back in chunks so the callback we setup to capture the response will be called multiple times with different parts of the response message.

  For example I have this code to call Twitter and return all my friends' status updates:

  var sys = require("sys"),
      http = require('http')
   
  exports.getTweets = function(callBack) {
      var twitter = http.createClient(80, "www.twitter.com");
      var request = twitter.request("GET", "/statuses/friends_timeline.json",
                                    {"host": "www.twitter.com",
                                     "Authorization" : "Basic " + "xxx"});
   
      request.addListener('response', function (response) {
          var tweets = "";
   
          response.addListener("data", function (chunk) {
              tweets += chunk;
          });
   
          response.addListener("end", function() {
              callBack.call(this, tweets);
          });
      });
   
      request.close();
  };
  

  I originally thought that the listener for 'data' would only be called once but it gets called 8 times sometimes so that I've created the 'tweets' variable which allows us to wait until we have the full response before firing the callback when the 'end' event is fired.

  I'm not sure whether I'm missing the point a bit by doing this and I think I possibly need to get more used to designing functions which can deal with streams rather than expecting to have all of the data.

• It seems like node.js would be perfect for a version of my colleagues Julio Maia and Fabio Lessa's http-impersonator which is a Java application used to record and replay requests/responses made across http-based protocols.

  I haven't quite worked out the best way to test the above code – ideally I want to stub out the HTTP request so that the test doesn't have to go across the wire. Micheil Smith pointed me towards fakeweb which allows the faking of HTTP requests/responses in Ruby so I'll probably have a go at creating something similar.

So far node.js seems really cool and writing code using it is really fun. I'm still not sure exactly where it will fit in some of the architectures that I've worked on but the model it encourages feels really natural to work with.

Despite the fact that none of the projects that I've worked on have used Git or Mercurial as the team's main repository I keep forgetting how useful those tools can be even if they're just being used locally.

I ran into a problem when trying to work out why a Rhino Mocks expectation wasn't working as I expected last week having refactored a bit of code to include a constructor.

I wanted to include the Rhino Mocks source code in our solution before and after the refactoring and step through the code to see what was different in the way the expectations were being setup.

My initial thought was that I could just check out the repository again in another folder and then include the Rhino Mocks source code there and step through it but unfortunately we have all the projects set up to deploy to IIS so Visual Studio wanted me to adjust all those settings in order to load the solution in the new checkout location.

I probably could have gone and turned off that setting but it seemed a bit too much effort and I realised that I could easily use Git to help me solve the problem.

I took a patch of the changes I'd made and then reverted the code before checking it into a local Git repository.

I updated the solution to include the Rhino Mocks code and then created a branch called 'refactoringChanges' so that I could then apply the patch that I'd created with my changes.

It was then really easy to switch back between the two branches and see the differences in the way that the Rhino Mocks was working internally.

The actual problem eventually turned out to be the way that the code calls Castle DynamicProxy but I didn't get the chance to look further into it - we had learnt enough to know how we could get around the problem.

I'm in the process of including the source code for all the 3rd party libraries that we use in the solution on a separate Git branch that I can switch to when I want to debug through that code.

Sometimes I end up having to close down Visual Studio and re-open the solution when I switch to and from that branch but apart from that it seems to work reasonably well so far.

James Shore has an interesting recent blog post where he describes some alternatives to over reliance on acceptance testing and one of the ideas that he describes is fixing the process whenever a bug is found in exploratory testing. He describes two ways of preventing bugs from making it through to exploratory testing:

• Make the bug impossible
• Catch the bug automatically

Sometimes we can prevent defects by changing the design of our system so that type of defect is impossible. For example, if find a defect that's caused by mismatch between UI field lengths and database field lengths, we might change our build to automatically generate the UI field lengths from database metadata. When we can't make defects impossible, we try to catch them automatically, typically by improving our build or test suite. For example, we might create a test that looks at all of our UI field lengths and checks each one against the database.

We had an example of the latter this week around some code which loads rules out of a database and then tries to map those rules to classes in the code through use of reflection.

For example a rule might refer to a specific property on an object so if the name of the property in the database doesn't match the name of the property on the object then we end up with an exception.

This hadn't happened before because we hadn't been making many changes to the names of those properties and when we did people generally remembered that if they changed the object then they should change the database script as well.

Having that sort of manual step always seems a bit risky to me since it's prone to human error, so having worked out what was going on we wrote a couple of integration tests to ensure that every property in the database matched up with those in the code.

We couldn't completely eliminate this type of bug in this case because the business wanted to have the rules configurable on the fly via the database.

It perhaps seems quite obvious that we should look to write these types of tests to shorten the feedback loop and allow us to catch problems earlier than we otherwise would but it's easy to forget to do this so James' post provides a good reminder!

If you are developping a VS addin or even if you are just a VS Addin user you certainly met this popup message in the past at VS startup time:

I can attest that this message box popups because of environment issue including:

• Missing file(s)
• Mismatch 32bits / 64bits mode
• Security issue: maybe one of the hardest to pinpoint: blocked DLL. A DLL might be blocked when unzipped on your hard-drive for security issue. Brad Abrams reported as well this problem here. You then need to unblock the Dll file addin entry point.

The main problem is that VS Addin developers don't even get a chance to prevent problems because typically, the popup message is shown before any IL instruction of the Addin get executed!

So at the very least, it is essential that the VS Addin loading failed popup message displays error message that are actually useful. Because it is an environment issue, the VS user could solve it easily by himself without all the friction of reporting the problem and waiting for a solution. For example I obtained the popup image above by deleting NDepend.Addin.dll, why don't I get a clear message like: missing Dll file xxx ?

We’ve covered a bit of ground already in this series on the Reactive Extensions for JavaScript (RxJS) from the basic information, creating observers and observables, jQuery integration and in the last post talking about composing asynchronous methods with callbacks.  Now that we have some more fundamental building blocks, let’s see what else we can do with it.  Since we talked about asynchronous methods last time and making them composable, how about this time taking a method that is seemingly a blocking AJAX call and turn it into an asynchronous method?  In this post, we’ll finish up the Microsoft Translator example by playing with the getLanguages and getLanguageNames methods and see what we can do with them.

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

• Introduction
• Creating Observables
• Creating Observers
• jQuery Integration
• Composing Callbacks

From Synchronous to Asynchronous

Just like before we’re going to use the Microsoft Translator.  This API, which is provided in several flavors (SOAP, AJAX and HTTP) allows us to not only translate but also detect the language of a given piece of text.  Just as well, there are other functions such as getting all languages codes and getting all language names by language code, and we’ll cover that part today.  Getting started, you need to apply for a developer key which you can get here.  From there, we can embed our JavaScript link in our HTML so that we can get started.

<script type="text/javascript"
        src="http://api.microsofttranslator.com/V1/Ajax.svc/Embed?appId=myAppId">
</script>

In this example, our ultimate goal is to merge together the language codes with the language names that are localized to Dutch, once again in honor of Erik Meijer in his team.  In order to get all the language codes, we need to make use of the getLanguages function which returns to us a string array of said codes. 

string[] Microsoft.Translator.getLanguages();

Next up, we need to be able to get the language names localized based upon a language code.  To do that, we’ll call the getLanguageNames function which has the following signature.

string[] Microsoft.Translator.getLanguageNames(
    locale); // Language code to localize language name

We already covered how we can take existing arrays and convert them to an observable sequence by using the Observable.ToArray method.  Let’s make that call a little cleaner by extending the Array prototype to include a toObservable function.

Array.prototype.toObservable = function() {
    return Rx.Observable.FromArray(this);
};

Now this gives us some nice syntax to turn any given array to an observable such as the following:

[1,2,3]
    .toObservable()
    .Select(function(x) { return x * x; })
    .Where(function(x) { return x % 3 == 0; })
    .Subscribe(function(x) { alert(x); });

And in the case of our getLanguages function we could do this:

function getLanguages() {
    return Microsoft.Translator.getLanguages().toObservable();
}

But in this case, it would be a blocking call to first get the array and then to turn it into an Observable.  Instead, we want to kick off the call to the getLanguages asynchronously.  We could use the ToAsync method…

// Returns IObservable<string[]>
function getLanguages() {
    return Rx.Observable.ToAsync(
        function() { Microsoft.Translator.getLanguages(); });
}

Unfortunately this wouldn’t work as it would yield, in C# parlance, an IObservable<string[]> which is certainly not what we want as we want each string to be given asynchronously.  So, how else could we do this?

We can achieve that with the Start function which takes no arguments and you return what you want to yield.  In this case, we’ll yield our getLanguages observable sequence which contains all of our language codes.  What this would give us, in C# parlance, is IObservable<IObservable<string>>, but what we want is just an IObservable<string>, and in order to make that happen, we must call the MergeObservable function which merges an observable sequence of observable sequences into an observable sequence.  Below is what the code should look like for taking our getLanguages and making it an asynchronous call.

function getLanguages() {
    return Rx.Observable.Start(function() {
        return Microsoft.Translator.getLanguages().toObservable();
    }).MergeObservable();
}

The same logic once again can apply to the getLanguageNames function as well yielding the following function:

function getLanguageNames(locale) {
    return Rx.Observable.Start(function() {
        return Microsoft.Translator.getLanguageNames(locale).toObservable();
    }).MergeObservable();
}

Now that we have both of our functions to be asynchronous, let’s merge these two together to list the language code with the localized language name (in Dutch of course).  To merge these two into one, we’ll use the standard Zip LINQ operator, which is new in .NET 4.0 as well as RxJS, which looks something like the following in pseudo code.

var observable = {
    ...
    function Zip(
        right,     // Right hand collection 
        selector); // Combining function
};

In this case of using the Zip, we’ll simply return an object with two properties, a locale and a language and then on the subscription, we’ll just append items to an unordered list.

$(document).ready(function() {

    getLanguages()
        .Zip(getLanguageNames("nl"), function(locale, language) {    
        return { locale : locale, language : language };
    }).Subscribe(function (result) {
        $("#languageNames")
            .append("<li>"+result.locale+" - "+result.language+"</li>");
    });

});

And that yields the following result:

So, there you have it, a case of turning a pretty interesting blocking call string array and turning it into an asynchronous observable sequence of strings.

Conclusion

Through the use of the Reactive Extensions for JavaScript, we’re able to take blocking calls such as our AJAX calls here and turn them into asynchronous observable sequences.  Through such methods as Start, or ToAsync, we’re able to take calls that are potentially expensive and have them run in a non-blocking fashion.  Next time, we’ll move onto taking examples in FlapJax and converting them into Rx to show how that might work.

This of course is only scratching the surface of what capabilities this library has and there is much more yet left to cover.  The question you’re probably asking now is where can I get it?  Well, for that you’ll have to stay tuned.  I hope to have more announcements soon about its general availability.

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.

There's a new video up on www.asp.net which aims to help developers pick between ASP.NET WebForms and ASP.NET MVC. The video boils down to 5 benefits per technology which Microsoft thinks you should consider.

Let's go over the points, shall we? First, ASP.NET WebForms:

1 - Familiar control and event base programming model

The claim here is that the ASP.NET model is comfortable for WinForm programmers (thankfully this unbiased analysis left out who it's more familiar for). This is largely accurate, but disingenuous. The differences between web and desktop cannot be overstated nor can one overstate how bad ASP.NET's (or any other framework) is at hiding the difference. "Familiar" is probably the right word to use so long as you recognize that, in this case, at best it means: superficial; at worst: a serious pain in the ass. Your knowledge of building a VB6 app will allow you to write a "Hello World" web application - great.

Familiarity can be a liability when it tries to force a square peg into a round hole.

It also largely relies on your inability (or unwillingness) to learn. Today, next month or even next year may not be the right time for you to learn something new - that's fine. Eventually, sticking with what you know, only because you know it, will kill your career and possibility part of your spirit.

2 - Controls encapsulate HTML, JS and CSS

It's true that in ASP.NET WebForms controls can, and frequently do, encapsulate HTML, JS and CSS. How this ads "value" is beyond me. You can't, and shouldn't, be trying to build website without a solid command of HTML, JS and CSS. Whatever programming language and framework you use, the ultimate output of any website is HTML, CSS and JavaScript. Your server code essentially generates a stream of characters, which a browser loads and renders. To suggest, or think, that generating HTML, CSS or JavaScript in C# has any advantage is insane. It'll be more complicated to learn, do and maintain - and the end result will be inferior. Its like saying we should write C# in VB.NET; or drive cars by bolting planes to the roof and getting in the cockpit.

3 - Rich UI controls included - datagrids, charts, AJAX.

Point 3 is a different perspective on point 2, which is a different way of saying point 1. However, it is the most interesting and important perspective. Fancy tables and charts, as well as client-side behavior, shouldn't be a server-side concern. This is fundamental to what we all know about good and bad design. Classic ASP was a mess because it intermingled presentation code with server side code. The value of WebForms is that presentation logic is now a server side concern. Do you really believe this? Would you consider generating your HTML from a stored procedure?

The claim also implies that by using ASP.NET MVC, you won't be able to have a rich UI. In truth, you won't only have access to a wider range of controls; you'll also avoid a bunch of poor abstractions, and generate JavaScript by writing JavaScript, css by writing css and html by writing html.

4 - Browser differences handled for you

I'm guessing that the claim is that some of the controls mentioned in point 3 might render different HTML based on the requesting browser. Guess what, most jQuery (or any other js framework) plug-ins are fully compatible with all relevant browsers because they too can generate different HTML. In fact, doing this on the client side is almost always better - since you can tell the exact capabilities of a browser.

Also, it would probably be better if you generated correct HTML, CSS and JS in the first place - something you can't normally control using ASP.NET WebForms. So not only is this really just a benefit because IE is a pain, but its only worth mentioning because points #1, #2 and #3 mean that you've lost complete control over doing it right in the first place.

5 - SharePoint builds on WebForms

Yes, if you use SharePoint, you'll have to use WebForms.

Now on to ASP.NET MVC:

1 - Feels comfortable for many traditional web developers

ASP.NET WebForms is familiar while ASP.NET MVC is comfortable - that's helpful. Nonetheless, when I see "traditional" I think "not-modern". A more honest counterpoint to the WebForms claim would be: "A more natural way to build web applications". WebForms tried to help WinForm developer's transition to the web. ASP.NET MVC is a model that better reflect the realities of programming on the web. It's more than just comfort, and has nothing to do with tradition.

2 - Total control of HTML markup

HTML, JS and CSS are yours to command. That doesn't mean you can't use controls to speed up development and improve your applications. The way this is worded sure makes it sound like MVC is a lot more work than WebForms though. It isn't.

3 - Supports Unit Testing, TDD and Agile methodologies

I'm not sure what the technology stack has to do with the development methodology, so we'll just ignore the last part. That aside, its true that MVC makes it possible to unit test your code. The counter point to that is that WebForms is essentially impossible to unit test. This also understates the architectural superiority and design of MVC - its doesn't only allow you to leverage a number of best practices, it itself is actually built around those same practices. Code that can be unit tested, regardless of whether it is or not, is almost always superior to code that cannot.

4 - Encourages more prescriptive applications

So if ASP.NET MVC lets you build you application the way you should be building it, should you infer that ASP.NET WebForm forces you to build applications the wrong way? Yes, you should.

5 - Extremely flexible and extensible

Both frameworks share this value - but ASP.NET MVC is more about building on top of existing code, while ASP.NET WebForms is more about hacking things until they work. If you think this means that ASP.NET MVC can only be useful once you've extended it, then you are wrong. It works great out of the box is is feature rich.

Other Stuff

The video goes on to make weird assertions, like the possibility of turning back and picking a different stack if you feel you've made the wrong choice because of how similar and how much infrastructure they share. The better solution is to pick the right technology because going back months or years into your project doesn't sound like good advice to me.

It also mentions that it's common to have some pages handled by MVC and others by WebForms. It's good to know that you can do this - especially since it's a good way to upgrade from WebForms to MVC. However, I'd hardly call it common or even recommended. It's a useful transitional tool which you should aim to get out of as quickly as possible.

Ultimately, the first 4 values of WebForms all boil down to the same thing: there's a System.Web.UI namespace which represents the wrong way to build a web app. There are good reasons to pick WebForms - but they all come down to time and practicalities of learning new things (and SharePoint). I won't tell you that you have to learn MVC, because that may not be practical for you. I'll repeat what I've said before, ASP.NET MVC and WebForms DO NOT serve different purposes and one is not better suited for a particular type of application than the other(except SharePoint). They are completely overlapping technologies, and ASP.NET MVC is superior to WebForms.

Sunday I leave to Vegas to attend my first MIX. It’s exciting to finally attend this event that has such an air of mystique around it. I’ll be speaking on how you can use MEF in SL4 to partition your applications across many XAPs in a fairly seemless fashion. My talk is short, but it’s going to be very focused. If you’ve heard of MEF but are not sure what to do with it, or you know MEF and want to see some new ways it can help you make your Silverlight apps offer a better user experience, come to this talk.

Microsoft Silverlight Optimization and Extensibility with MEF

Glenn Block in Lagoon B on Tuesday at 3:35 PM

Wouldn't it be nice if your team could add new features to your applications without all the headache they have to deal with today? With the Managed Extensiblity Framework (MEF) in 4.0 you can bolt your apps together dynamically on the fly. Adding new modules and features is as simple as deploying a new binary, you don't have to touch the existing code. You can even deploy those features as separate XAP files which can be loaded on-demand! Come to this talk for a quick tour of what MEF is, and learn how you can use it to beat out your competition.

So far in this series, we’ve covered some basic information about the Reactive Extensions for JavaScript (RxJS) including creating observables and creating observers as well as jQuery integration.  Now that we have a foundation in some of the basic building blocks, let’s actually do something interesting with it.  For example, how would we compose two AJAX calls together with callbacks?  In this post, we’ll explore using the Bing Translator in combination with jQuery and the RxJS.

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

• Introduction
• Creating Observables
• Creating Observers
• jQuery Integration

Detecting and Translating Text with the Microsoft Translator

One of the many examples I’ve played with involving asynchronous programming, especially with my F# samples as well as the Reactive Extensions for .NET is using the Microsoft Translator.  This API, which is provided in several flavors (SOAP, AJAX and HTTP) allows us to not only translate but also detect the language of a given piece of text.  Just as well, there are other functions such as getting all languages codes and getting all language names by language code, and we’ll cover that in a subsequent post.  Getting started, you need to apply for a developer key which you can get here.  From there, we can embed our JavaScript link in our HTML so that we can get started.

<script type="text/javascript"
        src="http://api.microsofttranslator.com/V1/Ajax.svc/Embed?appId=myAppId">
</script>

In this example, we’re going to first detect the language of the given piece of text and then translate it into another language.  In honor of Erik and his team, I decided on Dutch as the destination language.  In order to detect the language we need to call the detect function which looks like the following.  It takes in some text and then a callback which then will give us our result as the function parameter.

Microsoft.Translator.detect(
    text,      // Text of the unknown language 
    callback); // A callback on complete

Next, we need the ability to translate our text to Dutch once we’ve determined the source language.  In order to do so, we must call the aptly named translate function which we provide our text, a from language that we’ll provide from our detect function callback, our destination language and finally a callback which provides us with the resulting text.

Microsoft.Translator.translate(
    text,      // Text to translate 
    from,      // The source language
    to,        // The destination language
    callback); // The handling callback

What you’ve noticed from these two functions is that they provide callback functions for each.  If we want truly compositional behavior, our code could get quite messy especially if we’re doing anything such as filtering results, transforming, aggregating and so forth.  But for now, we’ll have a simple example of composing these callbacks together.  In order to do so, we have to turn these two functions, detect and translate into Observables.  So, how do we do that? 

In this case, we’ll make use of the AsyncSubject class which allows us to represent the result of an asynchronous operation.  This class will take one value and only one value and then caches it for all future calls and acts as both an Observer and an Observable.  So for each time we call this subsequently, it will not cause a side effect and instead yield us the cached calculated value.  We’ll then call the detect method with our text and a callback, and inside of our callback, we’ll yield the value with OnNext and then mark our sequence as completed by calling OnCompleted.  Finally, we’ll return our AsyncSubject as an Observable and hide the fact that it’s both an Observer and Observable.

function detect(text) {
    var subject = new Rx.AsyncSubject();

    Microsoft.Translator.detect(
        text,
        function(result) {
            subject.OnNext(result);
            subject.OnCompleted();
    });

    return subject.AsObservable();
}

The same also applies to our translate function in pretty much the same form as we have above.

function translate(text, from, to) {
    var subject = new Rx.AsyncSubject();

    Microsoft.Translator.translate(
        text,
        from,
        to,
        function(translation) {
            subject.OnNext(translation);
            subject.OnCompleted();
    });

    return subject.AsObservable();
}

Now, let’s compose these together in such a way that we first detect the language of the text and then translate.  To make that happen, we’ll use the SelectMany method which projects each value of our observable sequence to an observable sequence and flattens the resulting observable sequences into one observable sequence.  In this case, we’re only projecting one value to the next observable sequence.

var translator = detect(translateText)
    .SelectMany(function(detected) {
        return translate(translateText, detected, "nl");
    });

Of course we could do more like filter, scan, etc with this, but it’s a good start.  Now bringing it all together in a jQuery and RxJS way, we can now complete our example by wiring up our HTML to take the input from a textbox once a button has been clicked, translate it, and display the result.

$(document).ready(function() {
    $("#translateCommand")
        .ToObservable("click")
        .Subscribe(function(event) {

        var translateText = $("#translateText").val();
        var translator = detect(translateText)
            .SelectMany(function(detected) {
                return translate(translateText, detected, "nl");
            });

        translator.Subscribe(function(translated) {
            $("#translatedText").html(translated);
        });
    });
});

And now we can see it in action by entering a sentence and sure enough it detects it as English properly.

How can I be sure of that?  What if I want to perform a side effect during the process, such as displaying our detected language?  To do that, we can use the Do method which invokes some sort of action for its side effect for each item in the sequence.  We could then change our translator Observable to the following to enable that behavior.

var translator = detect(translatedText)
    .Do(function(detected) {
        $("#detectedText").html("Detected " + detected);
    })
    .SelectMany(function(detected) {
        return translate(translatedText, detected, "nl");
    });

Now we have a nice compositional and quite fluent chain which deals with asynchronous behavior.  Invoking it this time in Spanish, we get the following result.

We could go even further to aggregate counts of which language was detected over time by using the Scan function, but that’s for another time.

Conclusion

Through the use of the Reactive Extensions for JavaScript, we’re able to bring compositional behavior to that which had been harder to do, such as asynchronous callbacks.  We’re able to get code in a nice fluent manner that makes sense and let’s us focus on the core problem domain instead of scattering code within a bunch of callbacks which can lead to any number of race conditions.

This of course is only scratching the surface of what capabilities this library has and there is much more yet left to cover.  The question you’re probably asking now is where can I get it?  Well, for that you’ll have to stay tuned.  I hope to have more announcements soon about its general availability.

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.

I once posted a semi-serious post entitled The 7 Phases of Unit Testing. The phases are:

1. Refuse to unit test because "you don't have enough time"
2. Start unit testing and immediately start blogging about unit testing and TDD and how great they are and how everyone should do it
3. Unit test everything - make private methods internal and abuse the InternalsVisibleTo attribute. Test getters and setters or else you won't get 100% code coverage
4. Get fed with how brittle your unit tests are and start writing integration tests without realizing it.
5. Discover a mocking framework and make heavy use of strict semantics
6. Mock absolutely everything that can possibly be mocked
7. Start writing effective unit tests

I think the cycle I went through is extremely healthy - unit testing is something best learnt from practice and is something you refine over time. Judging by the comments on the original post, a lot of you agree.

Recently though, I've felt like adding another stage:

8 . Sometimes the best tests aren't unit tests

After awhile, it becomes obvious that some tests are significantly more meaningful when you expand your scope - say to include hitting an actual database. Narrow unit tests and wider integration tests can always work together; but I've found that, in some cases, more comprehensive tests can replace corresponding unit tests. This may not be a proper, but it is practical.

When I say unit test, I mean the smallest possible unit of code - generally a behavior. Most methods are made up of 1 or more behavior. I'd say that you shouldn't have too many methods with more than 6 behaviors (as a rough goal). As an obvious example, in NoRM this method helps identify the type of the items in a collection:

public static Type GetListItemType(Type enumerableType)
{
    if (enumerableType.IsArray)
    {
        return enumerableType.GetElementType();
    }
    if (enumerableType.IsGenericType)
    {
        return enumerableType.GetGenericArguments()[0];
    }
    return typeof(object);
}

Clearly, this method is a good candidate for 3 or 4 unit tests (one when the type is an array, one when it's a generic, one when its something else, and maybe one when its null).

As your code moves closer to the boundaries of 3rd party components, the value of unit testing may suffer. You'll still get the benefits of flushing out coupling and enabling safe refactoring (which shouldn't be underestimated), but you'll likely miss out on making sure things will work like they should in production. The solution can be to expand the scope of your tests to include the 3rd party component.

The most common example is database code. Testing a Save method by mocking the underlying layer might work, but there's value in making sure that the object actually does get saved. That isn't to say that a single test that hits the database is good enough - your Save method might be made up of multiple behaviors, some which are better validated with one form of testing than another.

Really, that's one of the key things to remember as you walk down this path - don't think that just because your method is actually saving an object that your job is done. There are likely other behaviors that aren't being tested at all. It's easy to abuse these types of tests and get a false sense of security. The other key is to make sure that it runs like a unit test - namely, that its fast, doesn't require any manual setup, and isn't dependent or doesn't break any other test.

Lately, I've seen interest in using in-memory databases for this type of thing. The benefit is that they are super fast and don't leave stale data. They also don't require special setup. On the downside you still aren't truly testing the most fundamental behavior of your method - that an object will be saved to the database in production. Even with the best O/R tool I've seen code work against one database but not work against another - due to a bug on my part. Writing a script that can automatically and quickly setup and teardown against the final database, and having your team members set up a local database, may or may not work for you (it'll depend on the nature of your team and your system).

Ultimately, the most important thing is that you have automated tests which aren't a nightmare to setup, maintain or run. Integration tests have more dependency and thus are more fragile, but can be an efficient way to verify correctness.

Just a quick run by posting from some discussions yesterday. I see many people using the State Pattern in their domains. More often than not though they are making a mistake that can be seen by analyzing the OO aspects of their code. Let’s go through a quick example of a Loan Application.

When its “In process” you can edit data on it or submit for approval.

When its “awaiting approval” you can no longer edit details data but you can approve or deny the application.

When its “completed” it has become immutable and can no longer be edited but may have some getters on it for viewing of historical data

I went through and made a quick little example of this

public interface ILoanApplicationState
{
    void Approve();
    void Deny();
    InterestRate GetApprovedInterestRate();
    InterestRate CalculateLikelyInterestRate();
    void SubmitForApproval();
    void ChangeDetails(LoanDetails details);
}

public class LoanApplicationState : ILoanApplicationState
{
    private LoanApplication parent;
    public LoanApplicationState(LoanApplication Parent)
    {
        parent = Parent;
    }

    public virtual void Approve() {}
    public virtual void Deny(){}
    public virtual InterestRate GetApprovedInterestRate() {}
    public virtual InterestRate CalculateLikelyInterestRate() {}
    public virtual void SubmitForApproval(){}
    public virtual void ChangeDetails(LoanDetails details) {}

}

public class InProcessState : LoanApplicationState
{
    public InProcessState(LoanApplication Parent) : base(Parent) { }

    public override void Approve()
    {
        throw new InvalidOperationException("Cannot approve an inprocess application");
    }

    public override void Deny()
    {
        throw new InvalidOperationException("Cannot deny an inprocess application");
    }

    public override InterestRate GetApprovedInterestRate()
    {
        throw new InvalidOperationException("No approved interest rate exists on an in process application");
    }

    public override InterestRate CalculateLikelyInterestRate()
    {
        return InterestRate.Default;
    }

    public override void SubmitForApproval()
    {
        //change parent state to submitted
    }

    public override void ChangeDetails(LoanDetails details)
    {
        //change parent details
    }
}

public class AwaitingApprovalState : LoanApplicationState
{
    public InProcessState(LoanApplication Parent) : base(Parent) { }

    public override void Approve()
    {
        //change parent state to approved and issue some behavior
    }

    public override void Deny()
    {
        //change parent state to denied and issue some behavior
    }

    public override InterestRate GetApprovedInterestRate()
    {
        throw new InvalidOperationException("No approved interest rate exists on an awaiting approval application");
    }

    public override InterestRate CalculateLikelyInterestRate()
    {
        return InterestRate.Default;
    }

    public override void SubmitForApproval()
    {
        throw new InvalidOperationException("Already awaiting approval");
    }

    public override void ChangeDetails(LoanDetails details)
    {
        throw new InvalidOperationException("No approved interest rate exists on an in process application");
    }
}

public class CompletedApplicationState : LoanApplicationState
{
    public InProcessState(LoanApplication Parent) : base(Parent) { }

    public override void Approve()
    {
        throw new InvalidOperationException("Application has already been completed");
    }

    public override void Deny()
    {
        throw new InvalidOperationException("Application has already been completed");
    }

    public override InterestRate GetApprovedInterestRate()
    {
        //return parents approved interest rate
    }

    public override InterestRate CalculateLikelyInterestRate()
    {
        //return parents approved interest rate
    }

    public override void SubmitForApproval()
    {
        throw new InvalidOperationException("Already completed");
    }

    public override void ChangeDetails(LoanDetails details)
    {
        throw new InvalidOperationException("Application is already completed");
    }
}

OK enough yucky code you guys get the idea (the state pattern is also very verbose). The idea here is we plug in these state objects to our object and they handle the behavior changes from the original object.

My contention here is that you should not use the State Pattern like this. Where is the polymorphism? What if we think about the gross violation of LSP that we just created? This does however happen way too often.

The solution is that we really have three classes here InProcessApplication, AwaitingApprovalApplication, and CompletedApplication.

public class InProcessApplication {

    InProcessApplication SubmitForApproval(ILoanProcessingService processor) { …  }

}

this will force us to end up with smaller and easier to understand classes… and I mean hey, its not like polymorphism would have worked before anyways. It also makes our Ubiquitous Language more concise.

There is a particular code smell here that will help us distinguish whether we want the State Pattern or separate classes. Do some of the data/behavior only make sense in certain states? If so use three separate classes. Going along with this, if we find “throws” in our state implementors we should realize through LSP that we are doing something bad.

This Thursday, I’ll be joining John Bristowe and Joey Devilla to talk about composite applications, patterns, MEF and anything else that comes up. I am flexible :-)

This is a live webcast where questions will be taken in real time, so ask away! I am selfish but no slides or demo prep sounds great to me!

Register here: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032439322&Culture=en-CA

In the last post we migrated over to the new DeploymentCatalog. In this post we’ll look at refactoring the code to incorporate the MVVM pattern. Code from the last post is available here

Why ViewModel?

There’s a ton of content out there in the blogosphere that discuss the virtues of separated presentation patterns including MVVM. I am not going to reiterate those here, but I will point you at Josh Smith’s excellent MVVM article here. I’ll also shamelessly plug my own post where I shared my own view on the essence of MVVM (which is based on views of others i respect). In short it’s about decoupling UI logic for better maintainability which includes making it easier for a graphic designer to style the UI.

So where are the maintainability issues in the current “app”? Currently the main place is within MainPage.xaml.cs where you see the following code:

public void OnImportsSatisfied()

{

    TopWidgets.Items.Clear();

    BottomWidgets.Items.Clear();


    foreach (var widget in Widgets)

    {

        if (widget.Metadata.Location == WidgetLocation.Top)

            TopWidgets.Items.Add(widget.Value);

        else if (widget.Metadata.Location == WidgetLocation.Bottom)

            BottomWidgets.Items.Add(widget.Value);

    }

}

The logic is simple yes, but it still has issues.

• The main issue is that it is mixing UI business logic with the rendering. The logic which determines which item goes to Top to Bottom is a completely separate concern from how those items actually get displayed. Having the logic mixed in means  the code is very brittle where any slight change to the way the UI is rendered can break it. It also makes it difficult for a graphic designer from being able to change the look and feel of how the widgets are rendered.
• The second issue is that I am imperatively adding elements to the UI rather than letting the rich DataBinding engine do the work it was designed for. This makes it difficult to re-skin the UI.
• Third, in it’s current form, the logic is difficult to test, meaning if the logic breaks I am relying on QA / manual testing to pick it up.

So ViewModel will fix all of this?

I say with confidence Yes! Using ViewModel will allow us to refactor the logic into a nice reusable and testable place. It will also gives us the decoupling we need to leverage the Silverlight rendering engine to it’s fullest. Along the way you will also see how MEF can help us with regards to implementing MVVM within our applications. We’ll introduce 2 view models to help us get there. When we’re done, our application will look like this.

Pre-requisites.

As with the last post, you’ll need our MEF codeplex bits for following along. If you start where we left off in the last post you’ll be fine. You’ll also need a copy of Laurent Bugnion’s awesome “Glenn Block approved” :-) MVVM Light, which you can get here and which we’ll be using for it’s ICommand default implementation.

Let the refactoring begin!

First we’ll go create our ViewModel. We’ll start off with an empty class. Go add a new MainPageViewModel.cs class to the HelloMEF project. Leave it empty for now. Now let’s refactor MainPage to have MEF deliver it’s ViewModel. There’s a lot of religous debate in the community around View First vs ViewModel First construction of the UI. I am going to use View first, period, and no that’s not open for debate :-)

Refactoring MainPageView

What we’re going to do is rip out the logic in MainPageView, and replace it with importing it’s ViewModel and setting it to the DataContext. Replace MainPageView.xaml.cs the following:

public partial class MainPage : UserControl

{

    public MainPage()

    {

        InitializeComponent();

        CompositionInitializer.SatisfyImports(this);

        this.DataContext = ViewModel;

    }


    [Import]

    public MainPageViewModel ViewModel { get; set; }

}

I think you’ll agree this code is a lot cleaner. My UI is now completely decoupled from any UI “logic”.

But WAIT, there IS code in the code behind, and the ViewModel police are probably on their way to my house. My answer when they show up is “it’s simple wiring logic, so WHAT!” That being said you can certainly look at ways to remove to right that small amount of code, but I am not losing any sleep over it. :-)

Notice I am not using constructor injection rather I am importing my ViewModel through a property. The reason is because I am allowing XAML to create my view rather than having MEF create it for me. SatisfyImports is then called to tell MEF to inject the view. It removes one level of mental gymnastics which in particular manifests itself when you start dealing with nested Views and ViewModels. If you’ve dealt with manually assembling Composite UIs / using regions, you know what I mean. It also allows this view to be more designer friendly as I can configure a design time VM to show up. That is for another post.

Fleshing out MainPage’s ViewModel

Now we’re go and finish the empty MainPageViewModel we created earlier. We’re not just going to move the code from the view into the model as we’d just be moving the problem. Instead we’re going to get rid of the imperative code and allow the view to render itself on the model through binding. We’ll still need to leverage MEF’s metadata and ensure that the widgets go in the right “place” wherever that happens to be. This raises a question as to how as previously there was a single collection of widgets that we imported into MainPage before and which we manually walked. The solution I chose was to create collection properties for each set of widgets. That allows the view to render it any way it wishes and decouples from the ItemsControls that were used previously.

Below is the code:

[Export]

public class MainPageViewModel : IPartImportsSatisfiedNotification, 

    INotifyPropertyChanged

{

    [ImportMany(AllowRecomposition = true)]

    public Lazy<UserControl, IWidgetMetadata>[] Widgets { get; set; }


    public IEnumerable<UserControl> TopWidgets { get; private set; }


    public IEnumerable<UserControl> BottomWidgets { get; private set; }


    public void OnImportsSatisfied()

    {

        TopWidgets = Widgets.Where(w => w.Metadata.Location == 

            WidgetLocation.Top).Select(i => i.Value);

        BottomWidgets = Widgets.Where(w => w.Metadata.Location == 

            WidgetLocation.Bottom).Select(i => i.Value);

        OnPropertyChanged("TopWidgets");

        OnPropertyChanged("BottomWidgets");

    }


    public event PropertyChangedEventHandler PropertyChanged;


    private void OnPropertyChanged(string property)

    {

        var handler = PropertyChanged;

        if (handler != null)

            PropertyChanged(this, new PropertyChangedEventArgs(

                property));


    }

}

MainPageViewModel implements IPartImportSatisfiedNotification as the view did previously. It also implements INotifyPropertyChanged in order to tell the view whenever it is recomposed. It exports itself in order to make itself available to be imported by the view. MainPageViewModel imports all the Widgets as did the view, but it also exposes two different properties TopWidgets and BottomWidgets. Whenever recompostion occurs, OnImportsSatisfied is called which updates these properties with their own filtered collections by using a LINQ query with the appropriate metadata filter. It then raises PropertyChanged in order to update the UI. This really shines through the power of metadata and metadata views in MEF!

Updating the bindings

The last thing we need to do to get the ViewModel wired is to update the view to bind the widget ItemControls to the appropriate properties. Replace the StackPanel in MainPage.xaml.

<StackPanel x:Name="LayoutRoot" Background="Black">

    <Border Background="Cyan">

        <ItemsControl x:Name="TopWidgets" 

            ItemsSource="{Binding TopWidgets}" Height="Auto" 

            FontSize="30">

        </ItemsControl>

    </Border>

    <Border Background="Yellow">

        <ItemsControl x:Name="BottomWidgets" 

            ItemsSource="{Binding BottomWidgets}" Height="Auto" 

            FontSize="30">

        </ItemsControl>

    </Border>

</StackPanel>

We’re almost there

Build and execute the app. You should see that everything works as before only now our new ViewModel is in place. You can now easily go and and reformat the UI without impacting the underlying ViewModel at all. We could stop here as we’ve already made a good leap in improving the maintenance of our app. We won’t though, there’s one more culprit we can refactor. Widget1.

What’s wrong with Widget1?

[ExportWidget(Location = WidgetLocation.Top)]

public partial class Widget1 : UserControl

{

    [Import]

    public IDeploymentCatalogService CatalogService { get; set; }


    public Widget1()

    {

        InitializeComponent();

        Button.Click += new RoutedEventHandler(Button_Click);

    }


    void Button_Click(object sender, RoutedEventArgs e)

    {

        CatalogService.AddXap("HelloMEF.Extensions.xap");

    }

}

Widget1 contains logic which calls the DeploymentCatalogService to download a XAP, it’s not horrible but it has some of the same problems as MainPage did.

• It tightly couples the download logic to the UI. This means if you refactor the UI there is a decent chance it will break.
  • Downloading widgets is a completely non-UI concern which does not belong in the view.
  • It means a designer can’t change from using a button without modifying the code.
• The logic is not reusable, you can’t reuse it across multiple views. This may or may not matter depending on the specific case.
• As small as it is, it is hard to test. That means if someone breaks the code and it no longer works, the only way to pick it up is through QA/automated UI testing. We want to pick up as many bugs as we can up stream rather than waiting for them to be caught.

Refactoring Widget1 to use a ViewModel.

Widget1 can be refactored to use it’s own ViewModel. We can then refactor the logic out of the code behind and move it into the model leveraging Silverlight 4’s new commanding support, Laurent’s MVVM light library, and a little MEF to make it more maintainable.

We’ll do this again with the ViewFirst approach :-) This time we don’t need to use CompositionInitializer though as our ViewModel will get discovered by the catalog. Add a new Widget1ViewModel.cs file to the HelloMEF project. Second add a reference to GalaSoft.MVVM light (in your “ProgramFiles\Laurent Bugnion (Galasoft)\Mvvm Light Toolkit\Binaries\Silverlight” folder). Now paste in the following code to Widget1ViewModel.cs.

using System.ComponentModel.Composition;

using System.Windows.Input;

using GalaSoft.MvvmLight.Command;


namespace HelloMEF

{

    [Export]

    public class Widget1ViewModel

    {

        public Widget1ViewModel()

        {

            Download = new RelayCommand(() => 

                CatalogService.AddXap("HelloMEF.Extensions.xap"));

        }


        [Import]

        public IDeploymentCatalogService CatalogService { get; set; }


        public ICommand Download { get; private set; }

    }

}

Widget1ViewModel is an export similar to MainPageViewModel. It imports IDeploymentCatalogService in order to allow downloading XAPs. It then exposes a Download command which is implemented using MVVM Lights’ (contributed by Josh Smith) RelayCommand to download the extensions.

Updating Widget1View

Once we have that in place we can clean up the Widget1 view. Paste the following into Widget1.xaml.cs.

[ExportWidget(Location=WidgetLocation.Top)]

public partial class Widget1 : UserControl

{

    public Widget1()

    {

        InitializeComponent();

    }


    [Import]

    public Widget1ViewModel ViewModel

    {

        get{ return (Widget1ViewModel) this.DataContext;}

        set { this.DataContext = value;}

    }

}

First I removed the previous UI logic. Then I added an import of the MainPageViewModel and set it to the DataContext. Constructor injection was also an option through usage of our ImportingConstructor attribute. I chose not to for consistency and in order to not increase the concept count. Feel free to use either approach though.

Now that we’ve updated the code behind we can update the XAML to bind to the new DownloadCommand. Replace the Grid element in Widget1.xaml with the following.

<Grid x:Name="LayoutRoot" Height="Auto">

    <Button x:Name="Button" Content="Hello MEF!" 

        Command="{Binding Download}" Width="300" Height="100">

    </Button>

</Grid>

Run the app!

Build and run the application, press the top button and you should see a screen that is quite familiar by now :-)

We’re done.

What did we gain?

You might be sitting there thinking wow that was fun, but what did it buy me? Here’s a quite summary:'

• MainPage and Widget1 are completely decoupled from the UI logic.
• MainPageViewModel and Widget1ViewModel are easily testable.

Both of which translate into less pain for us as our app evolves.

How did MEF help?

MEF enabled us to put the decoupled pieces back together. To be fair, we could have used other mechanisms. However MEF offered a nice solution in the box, which was convenient as our app was already using it :-) MEF also provided us CompositionInitializer which made it very easy to compose our UI parts without having to jump through a lot of hoops.

What’s next?

In this post I mentioned testing several times though notice I did not show ANY tests. That was deliberate :-) The reason is because I wanted you to see the value of ViewModel beyond the simple testability aspects, I wanted you to focus on how it improved our code whether we were testing it our not. In the next post we’ll look at how we can test it.

As always, code is attached.