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.

Continuing on with the series. In part III we introduced the concept of application partitioning through the use of the PackageCatalog which ships in the Silverlight toolkit. In this post we’ll take a look at a new API known as the DeploymentCatalog which ships in the box! We also look at some changes to our hosting APIs. If you are following along, the completed code from that post is available here.

Note: Instead of using the MEF binaries that ship as part of SL4 beta, we’re going to use our newer bits available on Codeplex from this point forward. It is very likely these same APIs will be available in the box when SL4 ships ;-)

DeploymentCatalog

With our latest codeplex drop we introduced a new API called DeploymentCatalog. DeploymentCatalog is basically a redesign of the catalog that we included in the toolkit. As part of the redesign we address some thread-safety issues as well as made the catalog more robust.

DeploymentCatalog (DC) is used for dynamically downloading MEF catalogs in an async fashion. To use it you call the DownloadAsync method passing in a uri with the default overload accepting a relative uri. The uri should point to a XAP which contains MEF parts. Once you initiate the download, DC will start the download. Upon completion DC will rip open the XAP, load all the assemblies within and add any attributed parts to the catalog. You’ll notice that unlike PackageCatalog which holds a collection of packages for multiple XAPs, each DC corresponds to a single XAP.

Below is a snippet of how to use it.

var catalog = new DeploymentCatalog("Extensions.xap");

catalog.DownloadAsync();

Passing deployment catalogs to PartInitializer

In the previous bits, CompositionHost.InitializerContainer was called in order to pass a container configured with a PackageCatalog which PartInitializer could use.In the new bits PartInitializer has been renamed to CompositionInitializer (more on that later). Additionally we’ve renamed InitializeContainer to Initializer and added a new convenience overload which accepts a param array of catalogs. When you use this overload you need to decide if you want the default XAP’s parts to be added. To do this pass in a DeploymentCatalog created with the default constructor such as the example below:

CompositionHost.Initialize(new DeploymentCatalog(), catalog);

Using the catalog from the previous example this will add all of the parts from the current XAP as well as any parts that are discovered in “Extensions.xap”.

Recomposition in DeploymentCatalog

Each DC downloads in an asynchronous manner. Because DC is recomposable (implements INotifyComposablePartCatalogChanged), it will notify whenever the download completes. This means that you are not required to subscribe to the DownloadCompleted event, as because the catalog is recomposable, it will force the container to recompose upon the receipt of parts. In the previous example, adding a catalog to DC does not mean that it’s parts have been downloaded yet. However once those parts are downloaded, the container will recompose.

Tracking completion, errors and progress.

You can, and we recommend you do track download completion and errors. Whenever a download completes, the catalog will raise a “DownloadCompleted” event. If the download fails for some reason, then DownloadCompleted will be fired setting the Error to the download error. You can also track overall progress of the download by subscribing to the DownloadProgressChanged event. Finally if your application logic requires it you can even cancel the download by calling CancelAsync.

For example see the snippet below.

void DownloadCatalog(string uri) {

    var catalog = new DeploymentCatalog(uri);

    catalog.DownloadCompleted += new EventHandler<AsyncCompletedEventArgs>(DownloadCompleted);

    catalog.DownloadProgress += new EventHandler<DownloadProgressChangedEventArgs>(DownloadProgressChanged);

    catalog.DownloadAsync();


    //cancel the catalog download due to a timeout

    catalog.CancelAsync();

}


void DownloadCompleted(object sender, AsyncCompletedEventArgs e)

{

    if (e.Error != null)

         throw e.Error;

}


void catalog_DownloadProgressChanged(object sender, DownloadProgressChangedEventArgs e)

{

  //progress logic here

}

Allowing parts to download XAPs.

In the last post we added the PackageCatalog directly to the container in order to allow parts to import it. A cleaner approach is to encapsulate the catalog management into a nice service that other parts can depend on. This allows the host to have more fine-grained control over how and what enters the container. In the sections that follow you’ll see I’ve introduced a DeploymentCatalogService for this purpose.

Migrating the code

OK, let’s start migrating the code to use the new DeploymentCatalog apis. Again the starter code is available here

Download MEF bits

First we need to go download the latest MEF bits from Codeplex from here. Extract the zip (make sure to unblock all files if you are letting windows extract it for you). Next open the HelloMEF solution in Visual Studio and go and remove all references to SystemComponentModel.Composition.dll, System ComponentModel.Composition.Initialization.dll, and SystemComponentModel.Composition.Packaging.Toolkit.dll from each project.

Fix MEF References

Now go add references to the newer binaries located in the .\bin\SL folder. Here are the projects and references.

• HelloMEF –> Add System.ComponentModel.Composition.dll and System.ComponentModel.Composition.Initialization.dll.
• HelloMEF.Contracts –> Add System.ComponentModel.Composition.dll.
• HelloMEF.Extensions –> Add System.ComponentModel.Composition.dll.

Introducing DeploymentCatalog service.

In order to handle initializing the host as well allowing other parts to download, we’ll create DeploymentCatalogService.

First add a new interface to HelloMEF.Contracts using the following code.

public interface IDeploymentCatalogService

{

    void AddXap(string uri, Action<AsyncCompletedEventArgs> completedAction = null);

    void RemoveXap(string uri);

}

Next add a new DeploymentCatalogService to the HelloMEF project.

[Export(typeof(IDeploymentCatalogService))]

public class DeploymentCatalogService : IDeploymentCatalogService

{

    private static AggregateCatalog _aggregateCatalog;


    Dictionary<string, DeploymentCatalog> _catalogs;


    public DeploymentCatalogService()

    {

        _catalogs = new Dictionary<string, DeploymentCatalog>();

    }


    public static void Initialize()

    {

        _aggregateCatalog = new AggregateCatalog();

        _aggregateCatalog.Catalogs.Add(new DeploymentCatalog());

        CompositionHost.Initialize(_aggregateCatalog);

    }


    public void AddXap(string uri, Action<AsyncCompletedEventArgs> completedAction = null )

    {

        DeploymentCatalog catalog;

        if (!_catalogs.TryGetValue(uri, out catalog))

        {

            catalog = new DeploymentCatalog(uri);

            if (completedAction != null)

                catalog.DownloadCompleted += (s, e) => completedAction(e);

            else

                catalog.DownloadCompleted += new EventHandler<System.ComponentModel.AsyncCompletedEventArgs>(catalog_DownloadCompleted);


            catalog.DownloadAsync();

            _catalogs[uri] = catalog;

        }

        _aggregateCatalog.Catalogs.Add(catalog);

    }


    void catalog_DownloadCompleted(object sender, System.ComponentModel.AsyncCompletedEventArgs e)

    {

        if (e.Error != null)

            throw e.Error;

    }


    public void RemoveXap(string uri)

    {

        DeploymentCatalog catalog;

        if (_catalogs.TryGetValue(uri, out catalog))

        {

            _aggregateCatalog.Catalogs.Remove(catalog);

        }

    }

}

DeploymentCatalogService handles adding / removal of DeploymentCatalogs. It also exposes a static Initialize method which handles setting up the host to allow dynamic download. This method creates an aggregate catalog, and adds the parts in the default XAP to it. It then calls CompositionHost.Initialize to pass that catalog to the host. Once the host has been configured, any catalogs added to the aggregate will then automatically show up in the host.

Note: DeploymentCatalogService is simply a helper, it is NOT required in order to use DeploymentCatalog.

Initializing the host

Now that DeploymentCatalogService is added, go remove the old Initialization code which used PackageCatalog from the App class and have it call Initialize.

private void Application_Startup(object sender, StartupEventArgs e)

{

    DeploymentCatalogService.Initialize();

    this.RootVisual = new MainPage();

}

Refactoring Widget1 to use DeploymentCatalogService

Next go change Widget1.xaml.cs replacing the importing PackageCatalog with IDeploymentCatalogService.

[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");

    }

}

Build it!

Go build the project and run it. Press the top “Hello MEF” button and you should see a new green part appear which was dynamically downloaded through the new DeploymentCatalog.

A few caveats about DeploymentCatalog.

DeploymentCatalog is a very exciting addition to the MEF box. There are a few caveats to it’s usage.

• Does not support Silverlight cached assemblies. (Otherwise known as TPEs). This means that DC will not download referenced assemblies that are packaged with the Silverlight caching infrastructure (.extmap).
  • This includes cached assemblies in the main xap.
  • If the cached assemblies are referenced by the main app, they will be available to the assemblies in a downloaded XAP.
  • You can create shared xaps which contain assemblies to be used by other xaps and download those with the DeploymentCatalog. As long as the shared xaps are downloaded first they will be available to others.
  • If you do decide to use either of the previous approaches, be sure to set your references to “Copy Local = False” in your XAPs otherwise you will be embedding the shared assemblies again.Does not support localization.
  • We are looking into cached assembly support in the future.
• Does not support non-embedded resources.
• Local resource references in XAML also are not supported i.e. using pack URIs. You can programatically access embedded resources though.

Summary

Used properly, DeploymentCatalog is a great way to partition your Silverlight applications in order to improve startup time as well as allowing third-parties to extend your Silverlight applications.

Completed code is attached.

My last musings on a observed misuse of ubiquitous language (UL) led to deeper comments than I had ever realized when writing the story down.

To many a non native speaker ubiquitous is at first hearing a strange word, as far as I know it is not widely used outside the world of IT. The sounding reminds of (un-)ambiguous, a term often found in the same context. There is a relation between these two words and IMHO that was the heart of the comments and led me to take another dive into the idea of UL.

The term Ubiquitous Language was brought to the world of software by Eric Evans in his classic book Domain Driven Design (DDD). Where it is defined as a language based on a model and spoken by both domain experts and developers. It should be “more robust than the lowest common denominator” (p.25). Domain experts “should object to terms or structures that are .. inadequate to domain understanding” and developers “should watch for ambiguity ..” (p.27) So a good UL is a powerful common unambiguous language spoken by all experts, whatever their background, to communicate on a software system.

Note the stress on the word expert. Now some people involved are not an expert. Take the old lady in my previous story, the recipient of UL. She might be very good in choosing what to buy and finding her way to the counter but when it comes to the technical rules of dealing with her payment she has all the right in the world to be a nitwit. As a domain expert you can consider her as something outside of the domain. To communicate in a safe way you can use an anti corruption layer (ACL). For the outgoing messages it will translate a lot of the domain specific facts and rules into a subset of commands like “Don’t do this” and “Please do that”. Which is perhaps not too friendly but at least it is unambiguous. But when it comes to incoming messages things get bad. These messages will be quite ambiguous. Like “I don’t understand”, without the sender even being able to make clear what she does not understand. Here we have a many to one mapping for outgoing messages and a one to many mapping for incoming messages. Where the latter can be quite ambiguous. “Would you please be so kind to explain what it is you don’t understand ?”.

The core of this problem is IMHO not an IT issue, it is just that the modern technological world is becoming too complex for more and more people. Be prepared for that yourself to. Just wait for the moment when you are going to give up on the new toolkit or methodology. That moment will come. According to the Peter principle I am almost there myself :)

As I mentioned we are learning the new enhancements in ASP.NET 4 and ASP.NET 4 Web Forms from scratch at the Sarasota Web Developer Group. At the first meeting we talked about many of the new enhancement in ASP.NET 4 Web Forms, including the new enhancements in ASP.NET 4 Web Forms Routing.

GetRouteUrl

In my last post I neglected to mention the Control.GetRouteUrl Method in System.Web.UI as a way to get routes from the route name and various route parameters. Using the following route from the previous post:

public class Global : System.Web.HttpApplication
{
    void Application_Start(object sender, EventArgs e)
    {
        RegisterRoutes(RouteTable.Routes);
    }

    void RegisterRoutes(RouteCollection routes)
    {
        routes.MapPageRoute(
            "Contact_Details",                  // Route Name
            "Contacts/Details/{id}",          // Url and Parameters
            "~/Contacts/Details.aspx"     // Page Handling Request
            );
    }
}

One can get the route for a particular contact inside a Page_Load Event, for example, by calling GetRouteUrl on the Page as follows:

protected void Page_Load(object sender, EventArgs e)
{
    var route = GetRouteUrl("Contact_Details", new { id = 1 });
}

The value of route in this case will be "/Contact/Details/1".

GetRouteUrl when DataBinding in Grid

The GetRouteUrl Method is particularly useful in a Grid when you want to display a list of contacts with a link to the details of each. Shown below is just a snippet of the Grid source code where I am using GetRouteUrl with the proper Route Name and Parameters within the NavigateUrl Property of the HyperLink:

<asp:TemplateField>
    <ItemTemplate>
        <asp:HyperLink
            ID="HyperLink1"
            runat="server"
            NavigateUrl='<%# GetRouteUrl("Contact_Details", new {id = Eval("Id") }) %>'
            Text='<%# Eval("Id") %>'>
        </asp:HyperLink>
    </ItemTemplate>
</asp:TemplateField>

Conclusion

I'll be posting about other topics presented at the group. If you live in the area, please come out and attend the second meeting focusing on ASP.NET MVC, DynamicData, Castle ActiveRecord, and more. I'll also be presenting What's New in ASP.NET 4 at the Orlando Code Camp.

David Hayden

BSON is a binary-encoded serialization of JSON-like documents, which essentially means its an efficient way of transfering information. Part of my work on the MongoDB NoRM drivers, discussed in more details by Rob Conery, is to write an efficient and maintainable BSON serializer and deserializer. The goal of the serializer is that you give it a .NET object and you get a byte array out of it which represents valid BSON. The deserializer does the opposite - give it a byte array and out pops your object. Of course, there are limits to what they can do - they are mostly meant to be used against POCO/domain entities.

Grammar
The first thing to understand when building serializers is how to read grammar. In programming languages, grammar is a way to express the valid keywords and values a parser might run into. Both the JSON and BSON grammars are great to learn, given how simplistic yet powerful they are. The JSON grammar, available on the homepage of json.org gives a nice representation of what valid JSON should look like. The BSON grammar, available at bsonspec.org under the specification button, follows a more traditional dialect. Essentially, you have symbols on the left and expressions on the right. The expressions can, and often will be, made up of additional symbols and or actual values. Eventually though, you'll end up with a symbol which is only made up of values - which means you can stop going down the rabbit hole. Its also very common for a child symbol to reference a parent symbol - but eventually something breaks this cycle.

An Example
So, say we wanted to serialize the following json:

{"valid": true}

Everything in BSON starts with a document. From the bson specification, we can see that a document is made up of a 32bit integer (representing the total size of the document, including the integer itself), another symbol called an e_list, and finally a termination character. As a start, we'd have something like:

Now, an e_list itself is made up of a symbol called an element followed by another e_list or an blank string. An element is made up of a single byte type (with \x08 representing a boolean), a symbol called e_name and a byte value for true or false. So now we have:

The only thing missing now is our e_name (which represents the word "valid" in the original JSON). An e_name is really just a cstring which is our value UTF8 encoded into an array of bytes with a trailing byte of \x00:

Our final byte array looks something like:

Serializing a single bool value might be the simplest of cases, but once you understand that, you're well on your way to being able to serialize anything. Sure, serializing an array might be a bit trickier, since each element within the array is its own document - but the challenge is mostly implementation versus conceptual.

What's the Length?
It may surprise you at first, but the most difficult part to implement is actually determining the length of a document (or various other symbols which have a length). The problem is that we don't know the length until after we've serialized it. Some implementations will essentially serialize the object graph twice, first to calculate lengths, then to write out the array. In NoRM we do things more efficiently. We keep a linked list of documents, and a pointer to the current document. A document is a very simple object - it keeps track of where it started, who its parent is (null in the case of the root document) and how much data was written. When a new document is needed - say when we start serialization, or when the grammar dictates that we need a new document (arrays or nested objects), we mark where we are and write out a placeholder length. Then, when the document ends, we seek to our placeholder, and write out the length. The relevant code looks like:

  private void NewDocument()
  {
      var old = _current;
      //we start the Written at 4 because of the length itself
      _current = new Document { Parent = old, Start = (int)_writer.BaseStream.Position, Written  = 4};      
      _writer.Write(0); //length placeholder
  }
  private void EndDocument(bool includeEeo)
  {
      var old = _current;
      if (includeEeo)
      {
          Written(1);
          _writer.Write((byte)0);
      }            
      _writer.Seek(_current.Start, SeekOrigin.Begin);
      _writer.Write(_current.Written); //override the document length placeholder
      _writer.Seek(0, SeekOrigin.End); //back to the end
      _current = _current.Parent;
      if (_current != null)
      {
          Written(old.Written);
      }

  }
  private void Written(int length)
  {
      _current.Written += length;
  }

EndDocument is pretty interesting. Since the length of a nested document contributes to the length of the parent document, we need to make sure to update the parent (now current) document with the length of the nested one.

Conclusion
Everything else is pretty straightforward in terms of serialization - largely reliant on reflection and reflection helpers. We use Jon Skeets reflection to delegate approach to make things even faster (something I truthfully don't fully understand). Currently our implementation has some coupling to other NoRM components. Hopefully one day the BSON stuff will be stand-alone. If you can't wait, you can either use another library like JSON.NET (which more mature anyways), or spend a few minutes (it shouldn't take more than that) pulling out our serializer/deserializer.