I'm currently in the process of writing the next to tutorials in my Windows Phone 7 tutorial series and thought I'd share these snippets of code.

They're pretty simple little helpers and can be used for any urls. The only thing that may need to change is the ToAbsolute method which is only for the root application. To the use the helpers in my blog I have the following.

Embeding Silverlight xaps in a page can be a pain in the ass, it's very verbose if you try and do it manually. I'm already using JQuery on the Compiled Experience Website so anything where I can use JQuery to simply this would be great.

The best example I've found of doing this is on the Silverlight Forums and is a great simple little plugin that lets you embed Silverlight xaps. I've modifed the example one slightly (mostly method names). Once you've included both JQuery and the plugin js file it's as simple as this to embed your Silverlight.

Most of the time I do any database interaction I follow a "Unit of Work" pattern. This allows good control over when work is submitted to the database, in terms of the Entity Framework, the Unit of Work controls the lifetime of the ObjectContext.

The implementation is pretty simple, we have a UnitOfWork static class that provides easy access to the current UOW as well as starting and disposing. We then have our IUnitOfWork which is where the work of accessing repositories and submitting changes to the database will be done. We then implement that with EntityUnitOfWork.

I like to follow the approach of "Unit of Work per Request" for web applications and usually handle this with an IHttpModule that manages it for me. However for MVC I wanted to try something different. One of the reasons I didn't like Module approach for MVC was that the UnitOfWork was still active during the rendering of the View. This meant that any complex lazy loaded queries could still be evaluated which could leave me vulnerable to N+1 problems.

In the end I created a UnitOfWorkAttribute which inherits from ActionFilterAttribute, this enables me to dispose of the current unit of work after the action is completed but before the view is processed. It means that if the view triggers anything that causes database access it throws an error. I can now enforce the convention that all data must be loaded by the action.

For the new version of the website I'm using the Data Annotations validators for validating view models posted to the controllers. As I'm sure everyone who starts down this road does one of the first things I wanted to create was an EmailAttribute by extending RegularExpressionAttribute. The mighty Scott Gu goes through this process in his blog post on Model Validation. Unfortunately his solution stops just short of everything that's required.

The EmailAttribute works correctly on the server but doesn't trigger any validation on the client side. What you need to do is inform the DataAnnotationsModelValidatorProvider (phew) that the EmailAttribute acts in exactly the same way as the RegularExpressionAttribute. This can be achieved with this simple bit of code in Application_Start.

A while ago I was looking into dynamic languages (in particular Iron Python) and an idea presented in a talk stuck with me. I wish I could remember who it was to credit them. In essence it was that in dynamic languages unit tests verify what the compiler can't enforce and that we can think of the compiler as simply another unit test in the system. This was obviously framed in a way that meant that the type safety wasn't necessary but lets approach it from a different direction.

Don't unit test what you can use the compiler to enforce.

A common thing I see in MVC examples is a unit testing verifying that some controller action returned the correct type of ActionResult e.g IndexReturnsViewResult. While this test is useful, we can remove it by changing the return type of Index to ViewResult, now the compiler enforces our test for us! This clearly won't work for actions that return different types of result depending on context (this is where unit testing should be testing). But if we can have our compiler enforce some of our specification then I think we should.