- JQuery Mobile

Ales Holecek: Windows 8 Unplugged

Thu, 17 Jan 2013 02:12:44 GMT

Ales Holecek opened the day at the p&p symposium this morning with a keynote address on Windows 8. Here are my live blogging notes that contain a mixture of his comments and my own commentary as he went along. Holecek is in charge of WinOS 8. He said that mobility was the primary driver for them when they started thinking about WinOS 8 back in 2009. Given that they promoted touch to a first-class citizen. Future releases will be optimized around touch. The holy grail for a future OS is speech but we're not there yet.

Holecek says that form factors (devices) are a moving target right now. They are shrinking for sure. But no one knows where the trend is going. Like everyone else Microsoft expects a lot of change in this area. Social media and web browsing in general are changing how they think about their OS. Users today expect data to follow them around on their tablet, phone, and laptop.

Holecek takes a trip down memory lane: in 1995 you had a stack of floppy disks on your desk. And if you had a PC you were sort of geeky. Today computing devices are a given.

Holecek reminded the devs in the audience that most people just want to get things done. Don't listen to industry pundits or bloggers who claim that if your app doesn't do "X" then it's too late and someone else has beat you to it. Focus on end users rather than pleasing the trend setters.

One paradigm that WinOS 8 embraces is connection to services. Internet connectivity is now a given. Gone are the days of the self-contained native app that stored data on your hard drive. WinOS 8 apps are lean and mean and state lives out in the cloud. Azure updates (every 3 weeks or so) are moving to support this paradigm (e.g., Azure web or mobile services).

WinOS 8 was built using open standards. C#, HTML, and Javascript are native languages in the OS. Interestingly enough you can build a Windows Store app using HTML and javascript. All native languages support async programming so that long-running tasks are no longer hanging on the UI thread. In fact, async will be a challenge (or at least cause a rethink) of many devs. Fortunately, .NET 4.5 makes async programming a lot easier.

As a dev you need to think about your app as a "global citzen" on the OS. The user is in control. Your app is run in isolation and has its resources throttled. Users want to install, run, and uninstall apps effortlessly.

In WinOS 7 an app was either running or terminated. In WinOS 8 an app can have a third state in between those two: suspended. The Task Manager will show this new state. A suspended app has no CPU time allocated to it. Users can resume an app that was suspended when they fip back to it. This all happens automatically by the OS process management when it realizes the app is longer in the foreground. An event will fire to say that your app is now suspended so you can handle that. So as a dev you need to think about the battery. You need to be efficient.

Holecek next ran through a demo in which he explained how the live tiles work. It's a lot like background computing. We went through a small code run building a live tile using C#. Essentially you ask the TileUpdateManager (a broker) for an updater. Then you tell it what periodic updates you want (for example hourly). Then you start the updater. I think it was about 3 lines of code. So the plumbing is out of the way and you can focus on your app.

Next he showed how he prepared his slide stack last night and ran through changes that get automatically synced between the phone, tablet and laptop via Skydrive and Onenote. It was very impressive. I have to say that Office 365 is very very impressive. Google apps looks really lame compared to Office on Skydrive. This is coming from someone who thought a few years ago that Office was dead.

That bar that pops out on the right hand side? Think of it as an OS contract that you should implement in your Win 8 app. The contract is brokered by the OS for you. It has search, share, and settings.

In closing he said that they're now at 60M WinOS 8 licenses. The number of apps in the store has quadrupled with more than 10K addd in the last month. Obviously, the ultimate success of Win 8 will depend on a rich ecosystem of apps for the new OS. Holecek emphasized that WinOS 8 is not a fad and they're not rolling back or rethinking their direction. So he made a "call to action": write Win 8 apps and start right now! :) Yes the certification process can take a month. Obviously their number one goal is to maintain confidence in the store and protect users from malicious apps. One bad (app)le can erode that confidence in a hurry. And it's hard to get it back. But they're learning. And they're improving the "onboarding pipeline." He asks for patience right now.

Greg Young on CQRS

Wed, 16 Jan 2013 04:52:04 GMT

When Greg Young's talk on CQRS began I was prepared for a long look at patterns, reliability, transactions, MQs with Azure, WCF, and interface contracts and how Microsoft products were the best way to get you from Point A to Point B. But I was wrong. He showed no code. He didn't mention Azure once. In fact, he didn't talk about specific tooling or tech stacks at all.

What we got was a refreshing reminder that as developers our data-centric approach to modeling and solving business problems is killing us. Young reminded us that state is a first-level derivative of the constant stream of events in the business. (An aside: this is an enduring concept in Buddhism too and the meaning of Heraclitus' dictum that you can never step in the same stream twice.) Simply put: tools and frameworks come and go but the concepts and ideas remain the same.

Young advised to stop looking at state and start looking at business problems as a series of events that taken together comprise the business process. "Try modeling the full process before the parts of the process." Also, forget the buzzwords. Look at the problem and the process, not "SQL Server" or "Azure Service Bus." To start with the tooling is "developer porn."

Event messaging has been around for thousands of years. The ancient Sumerians wrote accounting info on clay tablets and baked them. That document stored events in time. Immutable events. In fact, documents are built up of events (think of a passport with its many timestamps).

"Focus on strategic design first."

"There's no such thing as a one-way command." These are called "events." They happened in the real world. They cannot be rolled back. Commands and events are both just messages. We just give them different names.

Overall a fascinating talk because it said nothing new. In fact, I've been evangelizing this way of looking at business problems at my workplace. But this sort of back-to-basics wake up call is exactly what most of us need to hear.

ScheduleWidget Is Now Open Source

Tue, 25 Sep 2012 06:44:10 GMT

I had no idea that in the few short months since ScheduleWidget went live on NuGet it would be so popular. That tells me that other devs have a real need for the tool just like I did in my own project. That's the good news. The bad news is the feature requests are coming in and I can't support it alone. So she's going open source! I've created a repo and done the initial commit into GitHub. The repo on github.com is here. When I have time there are two features that I want to add:

(1) Allow quarterly events (in addition to one-time, daily, weekly, and monthly recurrences).

(2) Allow temporal expressions such as "the 24th of every month"

Maybe you'd like to contribute? That would be very much appreciated. If you're not familiar with github I highly recommend downloading GitHub for Windows. It's free and makes working with the repo a breeze. Then you're going to want to check out how to fork a repository in order to contribute to ScheduleWidget.

Maybe down the road I'll set up an automated build. But for right now it's just the raw source. When a good stable release is ready I'll be responsible for getting it into NuGet.

Pluggable Architecture in ASP.NET MVC 4

Sat, 15 Sep 2012 05:30:12 GMT

All problems in computer science can be solved by another level of indirection. --David Wheeler

...except for the problem of too many layers of indirection. --Kevlin Henney

Wouldn't it be cool to create a module that can be "plugged" into an existing ASP.NET MVC 4 web app? I'm going to walk through just such a solution. First let me say that I'm indebted to Long Le for his approach to the problem. I used his work as a basis for my own streamlined solution.

The bedrock of software engineering is to minimize coupling and maximize cohesion. This is one of those truisms that every geek is supposed to have tatooed on his arm or something. Of course I'm not sure if that will help you with the ladies. In any case, elements are said to be tightly-coupled if a change in one forces a change in the other. An element is cohesive if its functionality hangs together. For instance a class that parses strings, formats URLs, and creates text files has low cohesion. A class that does one and only one thing (parses strings) has high cohesion. Which do you think is easier to maintain a year from now?

So our goal is to create a "core" web application that changes very rarely and a series of plugins or modules that can be added over time. As far as the end user is concerned it looks like a single web application with new features popping up now and then. So let's start with the core web app.

Core Web Application

Create a MVC 4 web app using the basic project template. Call it "Core" (how imaginative). Add a HomeController to it as well as a default Index View with the following markup:

@{
    ViewBag.Title = "Index";
}

<h2>Welcome to the Core Web App</h2>
 
@Html.ActionLink("Plugin", "Index", "Plugin")

Fire it up and you should see the home page rendered. If you were to click on the link you'd get a 404 of course. Before we create the plugin we need to do four things:

Create an Areas folder where plugin views will live.
Reference and configure Ninject for constructor injection on the plugins.
Create a customized RazorViewEngine to support our plugins.
Register the custom view engine.

Create Areas Folder

Create a folder called Areas in the project root. This is where all of our plugin Views (areas) will live.

Ninject

A DI tool like Ninject is very helpful to our goal of minimizing coupling. We want to be able to bind instances to interfaces in the code. Yet, the core is completely ignorant of its plugins. So we can't just do something like this in the core when the kernel is created:

Bind<IPluginRepository>().To<PluginRepository>();

We need a way of binding that uses reflection through all present (and future) plugin assemblies to get the interfaces. So add the following three nuget packages:

Ninject
Ninject.MVC3
Ninject.Extensions.Conventions

After adding these packages the NinjectWebCommon bootstrapper is added to your App_Start folder. Go down to the RegisterServices method and add this code:

/// <summary>
/// Load your modules or register your services here!
/// </summary>
/// <param name="kernel">The kernel.</param>
private static void RegisterServices(IKernel kernel)
{
    // using System.IO;
    // using Ninject.Extensions.Conventions;
    // bind plugin assemblies in bin folder
    var path = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "bin");
    kernel.Bind(a => a.FromAssembliesInPath(path).SelectAllClasses().BindDefaultInterface());
}

As you can see we're pointing to the Core's bin folder and telling Ninject to find all assemblies there and create bindings for all of the concrete classes that implement an interface. So Ninject gives us the ability to add plugins at any time in the future and at app start the bindings will automatically be mapped for us. We'll see this in action in a little bit.

Customized RazorViewEngine

Next we have to override the default view engine with our own. To the project root add this class:

using System;
using System.Collections.Generic;
using System.IO;
using System.Reflection;
using System.Web.Mvc;

namespace Core
{
    public class CoreRazorViewEngine : RazorViewEngine
    {
        public CoreRazorViewEngine()
        {
            AreaMasterLocationFormats = new[]
            {
                "~/Areas/{2}/Views/{1}/{0}.cshtml",
                "~/Areas/{2}/Views/{1}/{0}.vbhtml",
                "~/Areas/{2}/Views/Shared/{0}.cshtml",
                "~/Areas/{2}/Views/Shared/{0}.vbhtml"
            };

            AreaPartialViewLocationFormats = new[]
            {
                "~/Areas/{2}/Views/{1}/{0}.cshtml",
                "~/Areas/{2}/Views/{1}/{0}.vbhtml",
                "~/Areas/{2}/Views/Shared/{0}.cshtml",
                "~/Areas/{2}/Views/Shared/{0}.vbhtml"
            };

            var areaViewAndPartialViewLocationFormats = new List<string>
            {
                "~/Areas/{2}/Views/{1}/{0}.cshtml",
                "~/Areas/{2}/Views/{1}/{0}.vbhtml",
                "~/Areas/{2}/Views/Shared/{0}.cshtml",
                "~/Areas/{2}/Views/Shared/{0}.vbhtml"
            };

            var partialViewLocationFormats = new List<string>
            {
                "~/Views/{1}/{0}.cshtml",
                "~/Views/{1}/{0}.vbhtml",
                "~/Views/Shared/{0}.cshtml",
                "~/Views/Shared/{0}.vbhtml"
            };

            var masterLocationFormats = new List<string>
            {
                "~/Views/{1}/{0}.cshtml",
                "~/Views/{1}/{0}.vbhtml",
                "~/Views/Shared/{0}.cshtml",
                "~/Views/Shared/{0}.vbhtml"
            };

            var fullPluginPath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "bin");
            foreach (var file in Directory.EnumerateFiles(fullPluginPath, "*Plugin*.dll"))
            {
                var assembly = Assembly.LoadFile(file);
                var plugin = assembly.GetName().Name;

                masterLocationFormats.Add("~/Areas/" + plugin + "/Views/{1}/{0}.cshtml");
                masterLocationFormats.Add("~/Areas/" + plugin + "/Views/{1}/{0}.vbhtml");
                masterLocationFormats.Add("~/Areas/" + plugin + "/Views/Shared/{1}/{0}.cshtml");
                masterLocationFormats.Add("~/Areas/" + plugin + "/Views/Shared/{1}/{0}.vbhtml");

                partialViewLocationFormats.Add("~/Areas/" + plugin + "/Views/{1}/{0}.cshtml");
                partialViewLocationFormats.Add("~/Areas/" + plugin + "/Views/{1}/{0}.vbhtml");
                partialViewLocationFormats.Add("~/Areas/" + plugin + "/Views/Shared/{0}.cshtml");
                partialViewLocationFormats.Add("~/Areas/" + plugin + "/Views/Shared/{0}.vbhtml");

                areaViewAndPartialViewLocationFormats.Add("~/Areas/" + plugin + "/Views/{1}/{0}.cshtml");
                areaViewAndPartialViewLocationFormats.Add("~/Areas/" + plugin + "/Views/{1}/{0}.vbhtml");
                areaViewAndPartialViewLocationFormats.Add("~/Areas/" + plugin + "/Areas/{2}/Views/{1}/{0}.cshtml");
                areaViewAndPartialViewLocationFormats.Add("~/Areas/" + plugin + "/Areas/{2}/Views/{1}/{0}.vbhtml");
                areaViewAndPartialViewLocationFormats.Add("~/Areas/" + plugin + "/Areas/{2}/Views/Shared/{0}.cshtml");
                areaViewAndPartialViewLocationFormats.Add("~/Areas/" + plugin + "/Areas/{2}/Views/Shared/{0}.vbhtml");
            }

            ViewLocationFormats = partialViewLocationFormats.ToArray();
            MasterLocationFormats = masterLocationFormats.ToArray();
            PartialViewLocationFormats = partialViewLocationFormats.ToArray();
            AreaPartialViewLocationFormats = areaViewAndPartialViewLocationFormats.ToArray();
            AreaViewLocationFormats = areaViewAndPartialViewLocationFormats.ToArray();
        }
    }
}

The Core project is complete. Now it's time to create a plugin for it.

Create the Plugin

Close the Core solution and create a new MVC 4 web application called "Plugin" using the Empty template. Add the Core project to Plugin and set it as the startup project. Go ahead and run it and click on the Plugin link. You should still get a 404 because we haven't created the plugin yet. Let's do that now. There are three things we need to do:

Create a simple interface to demonstrate how Ninject binding in the core works for us
Create a Plugin controller and an Index view for it
Create an AreaRegistration so that MVC menu routing will work

IMessageRepository

Let's keep it simple. We want to display a message on the view that comes from an interface implementation. Here's the interface, go ahead and add it to the project root:

namespace Plugin
{
    public interface IMessageRepository
    {
        string Message();
    }
}

And now here's an implementation:

namespace Plugin
{
    public class MessageRepository : IMessageRepository
    {
        public string Message()
        {
            return "Welcome to the plugin!";
        }
    }
}

Plugin Controller

Create a new PluginController class where we do constructor injection of the IMessageRepository:

namespace Plugin.Controllers
{
    public class PluginController : Controller
    {
        private readonly IMessageRepository _repository;

        public PluginController(IMessageRepository repository)
        {
            _repository = repository;
        }

        public ActionResult Index()
        {
            var message = _repository.Message();
            ViewBag.Message = message;
            return View();
        }
    }
}

Notice that we have not added Ninject to the plugin project. You could do that but what if you have dozens of plugins? The idea here is to add it just once to the core and have it work for all of the plugins in the application. Now create a default Index View by right-clicking on the word View and choosing Add View. Since we put the repository message in the ViewBag let's display it in our View. Add this snippet:

<p>@ViewBag.Message</p>

One last thing: Below the Views folder add a _ViewStart.cshtml file with the path to the Core master page:

@{
    Layout = "~/Views/Shared/_Layout.cshtml";
}

AreaRegistration

So that the routing engine picks up the new plugin area we need to add an AreaRegistration:

namespace Plugin
{
    // using System.Web.Mvc;
    public class PluginAreaRegistration : AreaRegistration
    {
        public override string AreaName
        {
            get { return "Plugin"; }
        }

        public override void RegisterArea(AreaRegistrationContext context)
        {
            context.MapRoute(
                "Plugin",
                "Plugin/{controller}/{action}/{id}",
                new { action = "Index", id = UrlParameter.Optional }
                );
        }
    }
}

Now we're code complete on our plugin. At this point we'd want to add an installer or your favorite web setup project to bundle up the plugin for later deployment. But I've noticed that none shipped with Visual Studio 2012 the other day. When WIX is ready as a nuget package for VS 2012 I'll probably use that but for now let's just keep things very simple. Edit the Plugin project properties (Alt+Enter) and make these two configuration changes:

(1) On the Build tab change the Output path to drop the Plugin.dll in the Core bin folder:

..\..\Core\Core\bin\

(2) On the Build Events tab add this post-build event command:

xcopy "$(ProjectDir)\Views" "..\Areas\$(ProjectName)\Views" /s /i /y

This will copy our plugin views over to the Core project's Areas folder that we created earlier.

Go ahead and build the solution and then run it. Now when you click on the action link you should get the message served up by the IMessageRepository implementation rather than a 404. If you get a runtime error double-check the path locations of the two build configurations above.

That's pretty much it. One of the things I've done is to create a separate WCF service called CoreService where I've fronted all of my ORM plumbing to the database with operation contracts. Any repository classes I have in my core or plugin assemblies can call a service for data. That way I can version the operation contracts and/or their implementations without needing to touch the core and its plugins. But that's a topic for another post.

ScheduleWidget 2.0 Released

Sat, 16 Jun 2012 09:23:18 GMT

Without much fanfare I'd like to announce the release of ScheduleWidget. ScheduleWidget is a .NET 4.0 scheduling engine that handles recurring events for calendars. I was influenced by Martin Fowler's white paper "Recurring Events for Calendars" in which he describes the broad software architecture for a recurring events scheduling engine. But I did not find any implementation of his idea in the wild. So this led me to write it myself. It is available as a nuget package here:

http://nuget.org/packages/ScheduleWidget

The page above has some unit tests to get you going on using the engine. As time permits I'll make some blog posts on how to use it effectively. For instance, it supports one-time only events as well as recurring schedules. But for now I'll just announce it and leave it at that. :)

JQuery Mobile Madness with MVC 4 Web API

Thu, 24 May 2012 05:48:04 GMT

In my last post I introduced MVC 4 Web API. In keeping with the spirit of things I'd like to throw a little JQuery Mobile into the mix for fun. As in my previous blog post fire up Visual Studio 11 Beta and create a new MVC 4 Web API project. Last time we posted a plain old string value back to the ValuesController. Now let's post a Widget class back. Go ahead and add this model to the project:

public class Widget
{
    public int ID { get; set; }
    public string Color { get; set; }
    public string Shape { get; set; }
}

Modify the ValuesController and replace the out-of-the-box Post verb method with this one:

public HttpResponseMessage<Widget> Post(Widget value)
{
    var r = new Random();
    value.ID = r.Next(1, 1000); // using System.Net;
    return new HttpResponseMessage<Widget>(value, HttpStatusCode.Created);
}

I'm really digging the new HttpResponseMessage. You can get really fancy with custom formatters here but I want to keep it really simple. So we're going to simulate a database call by just randomly picking an ID value and returning it back to the UI.

Ok now add this navigation method to the HomeController:

public ActionResult Widget()
{
    return View();
}

With that in place we need to provide a Widget view. Go ahead and add Widget.cshtml as a partial view in the Home folder and put in this simple Widget data entry form:

<ul data-role="listview" data-inset="true">

    <li data-role="list-divider">Create Widget</li>

    <li data-role="fieldcontain" class="ui-hide-label">
        <label for="widget-color">Color</label>
    <input type="text" name="widget-color" id="widget-color" value="" placeholder="Color"/>
    <label for="widget-shape">Shape</label>
        <input type="text" name="widget-shape" id="widget-shape" value="" placeholder="Shape"/>
    </li>

    <li data-role="fieldcontain">
        <input id="submit-button" type="submit" value="OK" />
    </li>

    <li id="post-result"/>
</ul>

<script type="text/javascript">
    $('#submit-button').click(function () {
        var color = $('#widget-color').val();
        var shape = $('#widget-shape').val();
        $.post("/api/values", { Color: color, Shape: shape },
            function (data) {
                $('#post-result').text('Success posting ' + data.Color + ' ' + data.Shape + 'widget with ID ' + data.ID);
            }
        );
    });
</script>

The last step is to put a plain old anchor tag in the Home Index.html page so that we can navigate to the data entry form. Insert this just above the H1 welcome tag:

<p>
    @Html.ActionLink("Favorite Widget", "Widget", "Home")
</p>
<h1>Welcome to ASP.NET Web API!</h1>

Enough code. Fire this guy up and make sure it works. Go ahead and click on the "Favorite Widget" link to be taken to the data entry form. Pretty ugly huh? That's because the markup in Widget.cshtml is using an unordered list that has no style. That's by design. I want to illustrate how JQuery Mobile transforms this into something that looks awesome on a smart phone.

To see this in action go into the Shared _Layout.cshtml file and replace the three references to the CSS and javascript files with these JQuery Mobile references:

<!-- JQuery Mobile -->
<p><link rel="stylesheet" href="http://code.jquery.com/mobile/1.1.0/jquery.mobile-1.1.0.min.css" /></p>
<script type="text/javascript" src="http://code.jquery.com/jquery-1.7.1.min.js"></script>
<script type="text/javascript" src="http://code.jquery.com/mobile/1.1.0/jquery.mobile-1.1.0.min.js"></script>

Now fire up the app and navigate to the form. Mobile friendly!

Fun with MVC 4 Web API

Thu, 24 May 2012 04:56:44 GMT

To check out the new Web API templates bundled up in Visual Studio 11, download and install VS 11 Beta.

In this walkthrough I'm using VS 11 Express for Web. Create a new ASP.NET MVC 4 Web Application and choose the Web API project template. Notice the new ApiController class from which ValuesController derives. Let's take it for a test drive. There are two action methods that implement the GET verb:

// GET /api/values
public IEnumerable<string> Get()
{
    return new string[] { "value1", "value2" };
}

// GET /api/values/5
public string Get(int id)
{
    return "value";
}

Go under Views/Home and edit Index.cshtml. After the last DIV tag add the following script:

<script type="text/javascript">
    $(document).ready(function () {
        $.getJSON("api/values", function (data) {
            $.each(data, function (key, val) {
                // useless but dramatic jQuery animation
                $('.round').append('<li class=' + key + '>' + val + '</li>');
                $('.' + key + '').text(val).animate({ fontSize: '+=5em' }, 1200);
                $('.' + key + '').text(val).animate({ fontSize: '-=5em' }, 1200);
            });
        });
});
</script>

This is just a simple JQuery ajax call to exercise the out-of-the-box ValuesController. Run it and see the cheap animation. But hey at least it wasn't a blink tag. To pass in an ID to the other GET method the above javascript could be modified to call url api/values/1 instead. How about posting? Modify the POST method to this so that we get back a warm fuzzy response:

// POST /api/values
public HttpResponseMessage<string> Post(string value)
{
    value = string.Concat(value, " processed!"); //using System.Net;
    return new HttpResponseMessage<string>(value, HttpStatusCode.Created);
}

Change the javascript to post a very exciting "value3" string to the controller:

<script type="text/javascript">
    $(document).ready(function () {
        $.post("/api/values", { value: "value3" }, function (data) {
            $('.one h5').text(data);
        });
    });
</script>

Run the app and you should see the response written to the first bullet list item.

Seismic Shifts in Web Development

Thu, 10 May 2012 23:56:18 GMT

Not really. But then again really. What I mean is the role of the web developer is changing fast and it's only been in recent months that I've looked up from my keyboard to see how the ground has shifted substantially. Some developer friends and I have often joked that the back end -- the database, object-relational mapping, domain model, business logic, and the controllers for the UI -- take us about a fraction of the time it takes us to get the UI right. We will sit for hours just to get the HTML right, float div tags, give up and go with the table tag, try again, move on, and so on and on. And now with awesome tools like EF and LINQ it's a breeze to do the sort of plumbing work that used to take weeks.

I think those of us who consider ourselves to be web developers need to come around to a simple truth. Increasingly we are needed for front-end skills and not the back end stuff. For some that will be a blow to the ego. I went to school for this stuff! I'm an engineer not a designer! But the demand now and into the future is going to be for the kind of web developer that knows everything from soup to nuts. Those who know jQuery, JSON, Ajax, Knockout.js, CSS3, good design principles, and can make a web page look and feel gorgeous will be worth their weight in gold. This will be our primary selling point and the back end stuff that we take so much pride in now will be a skill that's assumed. I'm not talking about very complicated business domains here of course. I'm talking about simple to medium complexity projects, the bulk of them out there, where the customer does not want to pay for a designer. In fact, he resents your suggestion and wonders why you can't make a web page look decent to save your life.

I used to be one of those developers who would surf for guidance on floating div tags only to run into yet another designer's blog who seemed more interested in showing off how clever, artistic, and utterly esoteric he could be rather than simply putting up clear and concise HTML markup. But I can't afford to sport that attitude any longer. The front end is changing fast and for the better with HTML5 and CSS3. I (and we) need to bridge the gap and move more into their camp. Right now if you call yourself a web developer you should read Ethan Marcotte's article entitled Responsive Web Design and other articles like it. This is where things are going. I've come to the conclusion that it's no longer enough to be a web developer who passes things off to a designer. We need to be designers as well.

Pattern Toolkit Builder (VSPAT)

Wed, 14 Mar 2012 06:41:51 GMT

A few days ago Jezz Santos at Microsoft Consulting announced the release of Pattern Toolkit Builder (VSPAT) for Visual Studio 2010. Why not VSPTB? I think PA originally stood for "pattern automation" and the marketing folks just haven't nailed this down yet. Anyway, this promises to be the sort of game changer I've been looking for in my organization. I remember the software factory idea that the P&P team worked on a few years ago. It sort of died on the vine. The idea with pattern automation or "software factories" is that a very senior developer can create interactive, prescriptive (or merely helpful), project templates that junior developers can use to get started on a new project. The toolkit lets you create guidance and proven patterns in the actual code that gets unpacked from the project template so that junior developers aren't faced with the "blank slate how-do-I-get-started" problem.

So you can imagine I was very eager to download the bits and take it for a spin. I have Visual Studio 2010 SP1 Ultimate. The prereqs for the extension are NuGet Package Manager v1.6.21215.x and VS 2010 SP1 SDK. I installed both. Unfortunately, I could not get VSPAT installed correctly. It installs without errors but a post-install configuration step fails. I looked at the activity log and it has to do with a conflict with another extension in the builder itself. The builder relies upon two other extensions: Pattern Toolkit Automation Library and Feature Builder Tools.

I tried various install/uninstall steps but nothing worked. I've commented at Santos' blog but I don't think he's checking in there. If anyone knows the fix for this I would love to get the answer.

[Update: Problem solved! See comments below...]

IncludeMetadataConvention Deprecated in EF 4.3

Fri, 17 Feb 2012 02:23:05 GMT

In an earlier blog post I showed how to remove the IncludeMetadataConvention convention from your DbContext configuration. This is necessary up through EF 4.2 to prevent model metadata changes from being written to the database, something you don't want for legacy systems. Beginning with EF 4.3 this pluggable convention has been deprecated. As posted on the ADO.NET team blog:

In CTP5 we have removed the need to perform additional configuration when mapping to an existing database. If Code First detects that it is pointing to an existing database schema that it did not create then it will 'trust you' and attempt to use code first with the schema.

Super cool. I like it when the tool trusts me. If I get a schema error then let me handle it in my fluent API mapping. Don't try to create tables or columns for me. So with the obsolesence of IncludeMetadataConvention the MyContext class is much simpler:

public class MyContext : DbContext
{
    public DbSet<Foo> Foos { get; set; }
    public DbSet<Bar> Bars { get; set; }
}

Entity Framework 5.0 Sneak Preview

Thu, 16 Feb 2012 01:24:50 GMT

In the upcoming EF 5.0 Microsoft has improved performance due mainly to caching of inline LINQ queries. The benchmarks are impressive:

Although EF will be twice as slow as native ADO.NET (I assume the benchmark here refers to a SqlDataReader) that is still an awesome trade off for the efficiency and maintainability you get from LINQ queries.

Polling with Knockout, JQuery, AJAX, and MVC

Thu, 02 Feb 2012 05:51:38 GMT

Some colleagues and I have been taking a close look at Knockout, the javascript library that implements the MVVM pattern for rich client UI. Knockout takes advantage of the new custom data attributes (data-*) in HTML 5 to bind declaratively a javascript view model to UI elements. That's pretty cool. But even better, Knockout will update your UI automatically whenever the underlying view model changes. It does this when you declare your model as an observable:

var WidgetViewModel = {
    shape: ko.observable('Square'),
    color: ko.observable('Purple'),
    teeth: ko.observable(12)
};

How about a demonstration? Let's say we want to monitor several running widgets and update their operational status on a web page every 5 seconds. That means polling with a timer. I'm going to show you one way to do it.

Fire up Visual Studio and create a new MVC 3 project called "WidgetMonitor". Knockout (currently v2.0) is available through NuGet so search for knockoutjs and add it to the project. You can also add it with the console by running the command Install-Package knockoutjs. In your _Layout.cshtml reference the library:

<script 
    src="@Url.Content("~/Scripts/knockout-2.0.0.js")" 
    type="text/javascript">
</script>

Add a new Widget model to your solution:

public class Widget
{
    public bool IsSpinning { get; set; }
    public string Shape { get; set; }
    public string Color { get; set; }
}

Now we need to modify our HomeController to return a collection of widgets. To keep it simple it will have a single GetWidgets method. And to make it interesting each widget will have a random boolean value for its IsSpinning property:

public class HomeController : Controller
{
    public ActionResult Index()
    {
        ViewBag.Message = "Welcome to SquareWidget.com!";
        return View();
    }

    [OutputCache(Duration = 0)]
    public JsonResult GetWidgets()
    {
        IEnumerable<Widget> widgets = new[]
        {
            new Widget { IsSpinning = CheckWidget(), Shape = "Round", Color = "Orange" },
            new Widget { IsSpinning = CheckWidget(), Shape = "Square", Color = "Purple" },
            new Widget { IsSpinning = CheckWidget(), Shape = "Triangular", Color = "Blue" }
        };

        return Json(widgets, JsonRequestBehavior.AllowGet);
    }

    private static bool CheckWidget()
    {
        Thread.Sleep(100);
        return new Random().Next() % 2 == 0;
    }
}

So far this is standard MVC stuff. Go to the Index.cshtml view for the HomeController. First, we're going to create a table to hold our widgets. The table will be ordinary in all respects except Knockout requires us to use declarative binding with the data-bind attribute for our properties that will be bound to the javascript view model:

@{
    ViewBag.Title = "Widget Page";
}

<h2>Widgets</h2>

<table>
    <thead>
        <tr>
            <th>Spinning</th>
            <th>Shape</th>
            <th>Color</th>
        </tr>
    </thead>
    <tbody data-bind="foreach: widgets">
        <tr>
            <td data-bind="text: spinning"></td>
            <td data-bind="text: shape"></td>
            <td data-bind="text: color"></td>
        </tr>
    </tbody>
</table>

The text binding is the workhorse of Knockout but there are others. Behind the scenes it will update the innerText (or textContent) for the element to which it is bound. Notice the foreach binding. Just like the foreach statement in C# this is the way you handle an array of data in Knockout.

Ok, we've got our UI above. Now let's dive right into the javascript. Below the table create a script region and declare a local variable called widgets:

<script type="text/javascript">

    var widgets = ko.observableArray([]);

</script>

According to the Knockout documentation on observables "if you want to detect and respond to changes on one object, you’d use observables. If you want to detect and respond to changes of a collection of things, use an observableArray." In our case we're monitoring a collection of widgets so we want to use an observableArray. Notice that it is initialized to an empty list. Below the array add these two view models:

function Widget(spinning, shape, color) {
    this.spinning = ko.observable(spinning);
    this.shape = ko.observable(shape);
    this.color = ko.observable(color);
}

function WidgetListViewModel() {
    var self = this;
    self.widgets = widgets;
}

Notice that Widget is sort of like a data transfer object, or at least identical to our server-side object. Each property is declared as an observable. The WidgetListViewModel is nothing more than a container for our widgets. When it is initialized or updated it will always set its local widgets property to the widgets observable array.

So far so good. We've got our client-side view models declared. Now for the polling part that will update them every 5 seconds. Below the WidgetListViewModel add these two functions:

function pollSystems() {

    widgets.removeAll();
        
    $.getJSON('/Home/GetWidgets', function (data) {
        $.each(data, function () {
            widgets.push(new Widget(this.IsSpinning, this.Shape, this.Color));
        });
    });

    setTimeout("pollSystems()", 5000);
}
    
$(function () {
    pollSystems();
});

Notice that most of this is just plain old jQuery. The document ready event calls the pollSystems function to kick things off. It will call setTimeout so it calls itself every 5 seconds. The Knockout magic comes in with the push function call. Knockout will add the new Widget to the widgets observableArray and then notify its listeners of the change. Those listeners will update your UI table automatically. What is the glue that binds the data-bind elements with the observables? The magic is with a function call applyBindings. Add it now:

ko.applyBindings(new WidgetListViewModel());

This is how you activate Knockout. Build and run the app and you should see a list of widgets that update every 5 seconds:

ChannelFactory, IDisposable and Handling Faults

Mon, 23 Jan 2012 10:27:52 GMT

In my last post (Poor Man's Publish-Subscribe WCF Service) I used the ChannelFactory to build a communication channel that I could use to call a WCF service. There's something about that implementation that I wanted to explain in more detail. Notice the try-catch block surrounding the using statement:

try
{
    var channel = BuildSubscriberClientChannel(subscriber);
    using (channel as IDisposable)
    {
        channel.Notify(eventCode);
    }
}
catch
{
    // in case using statement throws error
}

The ChannelFactory explicitly implements IDisposable.Dispose. And of course a call to CreateChannel returns an instance of the contract for the service. That's why I can convert the channel to IDisposable. This will force a call to Dispose, which is the same as a call to Close, when the code leaves the using block. But if an exception is thrown and the channel is faulted then you should be prepared to handle it. In my case I didn't want the exception to bubble all the way up to the client. So I wrapped it in a try-catch block. This is useful for another reason. I can let the GC take care of the faulted channel and create another one to retry the caller later.

Certainly channels are expensive to set up and tear down. But this is the cost of doing business when WCF services call each other. They have explicit boundaries and we're not dealing here with simple calls to objects on the heap. So you have to think about a strategy for what happens when the channel is faulted. In my case I wanted to build in some message durability. So in the catch block I save the message and subscriber ID in a local failed message table. Then I have a job that kicks off at regular intervals and checks the failed message table for messages. For each one it attempts to resend the message. On success it deletes the entry from the failed messages table. If the channel still faults or there is some other exception then it does nothing so that we can try again later.

Poor Man's Publish-Subscribe WCF Service

Fri, 20 Jan 2012 03:35:00 GMT

I'm going to describe a WCF implementation of a publish-subscribe pattern that is used here at a medium-sized organization where I'm a lead developer. For reasons I won't go into MSMQ and the cloud were not options for us. Yet we needed durability, reliability, and all of the goodness that comes with a service bus. So we rolled our own "poor man's" pub sub (or observer pattern) service a simplified version of which I'll describe here.

First a big shout out to Juval Loewy whose book Programming WCF Services describes a publish-subscribe framework. It's well thought out and I highly recommend it. My implementation is inspired by his framework. I'm going to assume you already know a good deal about WCF but if you don't get Loewy's book.

This diagram explains the pub sub architecture. A message or event is raised and sent to the publisher. The publisher in turn is responsible for notifying all of the subscribers of that event. In this way the originator of the message is decoupled from the subscribers.

I organized the WCF publisher service into three projects:

Publisher
Publisher.Contracts
Publisher.Domain

Publisher is the main WCF service application with two files: Publisher.svc and Web.config.

Publisher.Contracts contains the service and operation contracts for the Publisher service. And following Miguel Castro's advice I put all domain functionality, the models, repositories, and Entity Framework wiring into the separate Publisher.Domain project. This project is ignorant of WCF and can be reused in other solutions. I won't go into all of the EF plumbing but let's look at the Subscription model:

public class Subscription
{
    public int ID { get; set; }
    public string Name { get; set; }
    public string EventCode { get; set; }
    public string Address { get; set; }
    public string EndpointIdentity { get; set; }
}

By way of example if you wanted to simulate a SubscriptionRepository class to serve up test subscriptions here is one:

public class SubscriptionRepository
{
    public static IList<Subscription> GetSubscriptions(string eventCode)
    {
        return GetMockSubscriptions()
            .Where(s => s.EventCode == eventCode.Trim().ToUpper())
            .ToList();
    }

    private static IEnumerable<Subscription> GetMockSubscriptions()
    {
        return new[]
        {
            new Subscription()
            {
                ID = 1,
                Name = "Subscriber 1",
                EventCode = "EVENT_A",
                Address = "net.tcp://foo.com/Subscriber1/Subscriber.svc",
                EndpointIdentity = "serviceaccountuser@domain.com"
            },
            new Subscription()
            {
                ID = 2,
                Name = "Subscriber 1",
                EventCode = "EVENT_B",
                Address = "net.tcp://foo.com/Subscriber1/Subscriber.svc",
                EndpointIdentity = "serviceaccountuser@domain.com"
            },
            new Subscription()
            {
                ID = 3,
                Name = "Subscriber 2",
                EventCode = "EVENT_B",
                Address = "net.tcp://bar.com/Subscriber2/Subscriber.svc",
                EndpointIdentity = "serviceaccountuser@domain.com"
            },
        };
    }
}

So as you can see we have subscriptions and a repository to return them based on the event code passed in. The idea with the publish-subscribe pattern is that every publisher will have zero or more subscribers. In this example there is only one subscriber who wants to be notified when event code A is published. But there are two subscribers who want to be notified when event code B is published. Notice the Address and EndpointIdentity properties of a Subscription. That will come in handy later because given those two pieces of information we can create a channel to call the subscriber.

Let's look at the Publisher.Contracts project and the brains behind it all. The service contract does one thing and and one thing only:

[ServiceContract]
public interface INotification
{
    [OperationContract]
    void Notify(string eventCode);
}

Pretty straightforward. Before I describe the service itself let's look at a base class from which the service will derive. This base class has one job: given a Subscription build and return a communication channel that the publisher can use to communicate with the subscriber service.

public abstract class PublisherBase<T> where T : class
{
    internal static T BuildSubscriberClientChannel(Subscription subscriber)
    {
        var binding = CreateNetTcpBinding();
        var endpoint = CreateEndpointAddress(subscriber);
        return ChannelFactory<T>.CreateChannel(binding, endpoint);
    }

    internal static NetTcpBinding CreateNetTcpBinding()
    {
        var binding = new NetTcpBinding
        {
            ReliableSession = { Enabled = true },
            TransactionFlow = false,
            Security = { Mode = SecurityMode.Transport }
        };

        binding.Security.Transport.ClientCredentialType = TcpClientCredentialType.Windows;
        binding.Security.Transport.ProtectionLevel = ProtectionLevel.EncryptAndSign;
        binding.Security.Message.ClientCredentialType = MessageCredentialType.Windows;
        return binding;
    }

    internal static EndpointAddress CreateEndpointAddress(Subscription subscriber)
    {
        var uri = new Uri(subscriber.Address);
        var identity = EndpointIdentity.CreateUpnIdentity(subscriber.EndpointIdentity);
        return new EndpointAddress(uri, identity, new AddressHeaderCollection());
    }
}

For the sake of simplicity in this post, I'm making some design-time decisions. All of our subscribers must use the net.tcp protocol, authenticate with Windows Kerberos security, and communicate over an encrypted transport. The identity used to authenticate the call (serviceaccountuser@domain.com) is a user principal name that your sysadmin will need to configure on the IIS server:

    setspn -a HTTP/domain.com DOMAIN\serviceaccountuser
    setspn -a HTTP/server DOMAIN\serviceaccountuser

Like I said earlier I'm going to assume you're up to speed on WCF security. See Loewy's book or MSDN for selecting transport and credential types in your particular situation. I can tell you that the security here is perfect for an intranet environment. By choosing transport security as our security mode the channel over which the messages are sent is both encrypted and signed. I have not seen performance issues with this configuration. And it's way better than the old days when an ASMX service had to send and receive SOAP packets over a much slower SSL. Other than the decision to use NetTcpBinding in an intranet scenario I'm using the ChannelFactory class to generate the communication channel we'll need to call the subscriber.

Last, we need to create a PublisherService that implements our INotification service contract (the Notify operation). But I want to do it in such a way that the caller is not hanging out waiting a long time for the request-reply operation to complete. If there are 12 subscribers for an event then I don't want the caller blocking and taking up that connection while our publisher service generates 12 channels and calls each subscriber before a TimeoutException occurs. I could have configured a one-way operation and perhaps you'll want to do that. But for our purposes here I'm using a simple delegate function to pass off the work to another thread so I can respond back to the client right away.

[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerCall)]
public class PublisherService : PublisherBase<INotification>, INotification
{
    public delegate void PublishEventDelegate(string eventCode);

    public void Notify(string eventCode)
    {
        var eventDelegate = new PublishEventDelegate(PublishEvent);
        eventDelegate.BeginInvoke(eventCode, null, null);
    }

    private static void PublishEvent(string eventCode)
    {
        var subscribers = SubscriptionRepository.GetSubscriptions(eventCode);
        foreach (var subscriber in subscribers)
        {
            try
            {
                var channel = BuildSubscriberClientChannel(subscriber);
                using (channel as IDisposable)
                {
                    channel.Notify(eventCode);
                }
            }
            catch
            {
                Debug.WriteLine("Unable to publish event to subscriber");
            }
        }
    }
}

That's pretty much it. The PublisherService receives an event code (a very generic payload in this case, perhaps a more robust data contract in your situation) and for each subscription to that event creates a communication channel and calls the Notify operation. Notice the catch block. What I did in my implementation was build in some durability there instead of just throwing it away. Perhaps I'll describe that in another blog post.

Here's my service configuration in Web.config:

<service
    name="Publisher.Contracts.PublisherService"
    behaviorConfiguration="publisherServiceBehavior">
    <endpoint
      address="net.tcp://localhost/Publisher/Publisher.svc"
      binding="netTcpBinding"
      contract="Publisher.Contracts.INotification"
      bindingConfiguration="reliableTCPBinding" />
    <endpoint
      address="mex"
      binding="mexTcpBinding"
      contract="IMetadataExchange"
    />
</service>

There's not much to the binding because the security was done programmatically above in the PublisherBase class:

<bindings>
  <netTcpBinding>
    <binding name="reliableTCPBinding">
      <reliableSession enabled="true" />
    </binding>
  </netTcpBinding>
</bindings>

The service behavior is straight out of the box:

<behaviors>
  <serviceBehaviors>
    <behavior name="publisherServiceBehavior">
      <serviceMetadata 
          httpGetEnabled="true" 
          policyVersion="Policy12" />
      <serviceDebug 
          httpHelpPageEnabled="true" 
          includeExceptionDetailInFaults="true" />
    </behavior>
  </serviceBehaviors>
</behaviors>

We now have a bare-bones secure publish-subscribe service. There's room for improvement. For instance Loewy's implementation supports concurrent publishing of the events with a WaitCallback delegate function. So if it's important for all of the subscribers to get notifications in near real time then you'll want to take a look at that. Message durability is also missing in this example. What I did was to save the failed message for that subscriber in a local store. Then I have a process to check for failed messages at regular intervals and to try to resend them. That's the "poor man" part of this implementation because you get that for free with MSMQ. But it works like a champ so I'm not going to complain.

Snuggle up to jquery $.ajax

Sat, 18 Jun 2011 16:49:00 GMT

In an earlier post I described how to use the MVC 3 Ajax.ActionLink to post an async delete back to the server. Ajax.ActionLink depends upon jquery.unobtrusive-ajax.js, a script included with the MVC 3 project template. As Brad Wilson has blogged, and I demonstrated, you create an AjaxOptions class and pass it into the ActionLink method constructor. When the view is rendered those properties are emitted with the anchor tag as HTML 5 data-* attributes:

<a data-ajax="true" 
   data-ajax-confirm="Are you sure you want to delete this widget?" 
   data-ajax-method="POST" 
   data-ajax-success="deleteConfirmation" 
   href="/Widget/Delete/1">Delete</a>

Enter the jquery.unobtrusive-ajax.js script. I won't go into too much detail (because you can see it for yourself) but essentially the asyncRequest function takes those HTML 5 data attributes and builds a call to the jquery $.ajax function. Is it just a wrapper? Well yes, but a very convenient one because it promotes strong typing in your razor view and saves you from the messy details of creating a $.ajax function call on your own.

If you don't like the Ajax.ActionLink helper you're always free to roll your own. And it's easy. Take the same project from my previous blog post. Nothing changes with the Widget and WidgetController classes. Now in the Index.cshtml file replace the Ajax.ActionLink with a plain old anchor tag:

<a href="javascript:void(0)" id="@item.Id" class="delete-widget-link">Delete</a>

Then replace the script region with the following ajax funtion call:

<script type="text/javascript">
 
    $('.delete-widget-link').click(function() {
        // get the id of the selected widget
        var id = $(this).attr("Id");
 
        // delete on server
        $.ajax({
            type: "POST",
            url: "Widget/Delete/" + id,
            success: handleDeleteSuccess,
            error: function () {
                $('#actionMessage').text('Delete failed...');
                $('#actionMessage').effect("highlight", {}, 3000);
            }         
        });
    })
 
    function handleDeleteSuccess(data) {
        // remove the row from the table
        var rowId = "#widget-id-" + data.id;
        $('.widgets').find(rowId).remove();
 
        // display a status message with highlight
        $('#actionMessage').text(data.message);
        $('#actionMessage').effect("highlight", {}, 3000);
    }
    
</script>

That's it. You're still unobtrusive. But you're now making a direct call to the jquery $.ajax function instead of going through the jquery.unobtrusive-ajax.js script.

InvalidOperationException Using EF Code First

Thu, 09 Jun 2011 14:26:00 GMT

If you're using EF 4.1 "Code First" and make changes to your model you get the following error:

System.InvalidOperationException was unhandled by user code
Message=The model backing the 'MyContext' context has changed since
the database was created. Either manually delete/update the database,
or call Database.SetInitializer with an IDatabaseInitializer instance.
For example, the DropCreateDatabaseIfModelChanges strategy will 
automatically delete and recreate the database, and optionally seed it
with new data.

I've mentioned this in previous blog posts and it's annoying. If you want to make it go away add the following line to your DbContext instance. Just remember, by doing this you're telling EF that you will be responsible for keeping the mapping between the database and your entities in sync.

public class MyContext : DbContext
{
    public DbSet<Foo> Foos { get; set; }
    public DbSet<Bar> Bars { get; set; }
 
    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);
        modelBuilder.Conventions.Remove<System.Data.Entity
           .Infrastructure.IncludeMetadataConvention>(); 
    }
}

Taking Your Game to the Next Level: FluentValidation

Mon, 06 Jun 2011 17:06:00 GMT

This is the last in a three-part series on validation techniques in MVC 3. See the first post and the second post to get the solution set up.

Try this experiment: make sure your Global.asax Application_Start or database context does not have a database SetInitializer method exposed. That's the one that drops and recreates the database if the model changes. Ok, now go into your Widget model class and remove an attribute. Maybe one of the [Required] attributes above Name or Color. Now build and run the app and go to the Widget list. Yep, the app throws an InvalidOperationException with the error message "The model backing the 'WidgetApplicationContext' context has changed since the database was created." Oops, that would mean your database gets wiped out and you have to re-run your populate scripts. Nice huh?

So why do we care? We'll have our properties decorated at design time and we won't mess with them. That's true for the obvious ones like GreaterThan, Length, or Required. But what about the custom attributes? NameAvailableAttribute is required today but it might not be tomorrow. We might have other business rules we want to implement as we go along and what a hassle it would be add and remove attributes, thus breaking our EF model. Wouldn't it be cool to decouple as much as possible the validators and business rules from the model class? There are several good ways to do it but I want to illustrate FluentValidation written by Jeremy Skinner because I think it's one of the most elegant solutions to this problem.

To install make sure you have nuget installed. Then right-click on your References folder and choose "Add Library Package Reference". Search online for FluentValidation and install the FluentValidation.MVC3 package.

If you look at part two in this series you'll notice that our Widget class is pretty busy. I don't know about you but I don't really like those validation attributes over each property (of course they are needed for client-side javascript validation). Also, for anything but the most trivial application putting all of your business rules in the Validate method is not going to work. FluentValidation will let us abstract the validator attributes and the business rules out into a separate class. Once they're there we can remove and add business rules all day long and we won't break our EF backing model.

Let's get started. Create a new class in your Validators folder called WidgetValidator. Then move all of your rules into it so it looks like this:

using System.Linq;
using WidgetApplication.Models;
using FluentValidation;
 
namespace WidgetApplication.Validators
{
    public class WidgetValidator : AbstractValidator<Widget>
    {
        private const int MIN_RED_TEETH = 0;
        private const int MAX_RED_TEETH = 6;
        private const int MIN_BLUE_TEETH = 8;
        private const int MAX_BLUE_TEETH = 12;
 
        public WidgetValidator()
        {
            RuleFor(w => w.Name).NotEmpty();
            RuleFor(w => w.Name).Length(1, 10);
            RuleFor(w => w.NumberOfTeeth).NotEmpty();
            RuleFor(w => w.Color).NotEmpty();
            RuleFor(w => w)
                .Must(BeValidRedColor)
                .WithName("NumberOfTeeth")
                .WithMessage("Wrong red tooth count.");
            RuleFor(w => w)
                .Must(BeValidBlueColor)
                .WithName("NumberOfTeeth")
                .WithMessage("Wrong blue tooth count.");
            RuleFor(w => w)
                .Must(NameIsAvailable)
                .WithName("Name")
                .WithMessage(ValidationMessagesResource.NameIsTaken);
        }
 
        private static bool BeValidRedColor(Widget widget)
        {
            if (widget.Color.ToUpper().Equals("RED"))
            {
                if (widget.NumberOfTeeth < MIN_RED_TEETH || 
                    widget.NumberOfTeeth > MAX_RED_TEETH)
                    return false;
            }
            return true;
        }
 
        private static bool BeValidBlueColor(Widget widget)
        {
            if (widget.Color.ToUpper().Equals("BLUE"))
            {
                if (widget.NumberOfTeeth < MIN_BLUE_TEETH || 
                    widget.NumberOfTeeth > MAX_BLUE_TEETH)
                    return false;
            }
            return true;
        }
 
        private static bool NameIsAvailable(Widget widget)
        {
            var context = new WidgetApplicationContext();
            var widgets = context.Widgets.ToList();
            return (!widgets.Any(w => w.Name.ToLower().Equals(widget.Name.ToLower())));
        }
    }
}

That greatly simplifies our Widget class. Now our Validate method just needs to call the WidgetValidator to get any broken rules:

using System.Collections.Generic;
using System.ComponentModel.DataAnnotations;
using System.Linq;
using WidgetApplication.Validators;
using FluentValidationResult = FluentValidation.Results.ValidationResult;
 
namespace WidgetApplication.Models
{
    public class Widget : IValidatableObject
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public int NumberOfTeeth { get; set; }
        public string Color { get; set; }
 
        public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
        {
            var validator = new WidgetValidator();
            var results = validator.Validate(this);
 
            return results.Errors.Select(e => 
                new ValidationResult(e.ErrorMessage, new[] { e.PropertyName })
            );       
        }
    }
}

That's much cleaner. Our Widget class doesn't know about the business rules, all it knows is that the WidgetValidator has them and will return any broken ones through its IValidatableObject Validate wrapper. You'll notice also that pretty much any kind of business rule you can think of can be accomodated in this pattern. There are RuleFor validators for plain old Required and Length attributes, RuleFor validators for cross-property validation on the class between Color and NumberOfTeeth, and in the NameIsAvailable method there is even a call to the database.

Class-Level Validation in MVC 3 with IValidatableObject

Mon, 06 Jun 2011 12:36:00 GMT

In a previous post I covered simple and custom validators for model properties. Do read that post first to get a sample MVC 3 solution set up. Essentially at this point we have one out-of-the-box and one custom validator on our Widget class:

public class Widget
{
    public int Id { get; set; }
 
    [Required]
    [NameAvailable]
    public string Name { get; set; }
}

Now let's say a widget has two new required properties: NumberOfTeeth and Color. Here we go:

public classWidget
{
    public intId { get; set; }
 
    [Required]
    [NameAvailable]
    public stringName { get; set; }
 
    [Required]
    public int NumberOfTeeth { get; set; }
 
    [Required]
    publicstring Color { get; set; }
}

We need to modify our faked out list in WidgetController to return a list with the new properties:

//
// GET: /Widget/
 
public ViewResult Index()
{
    var widgets = new List<Widget>
    {
        new Widget() 
        {
            Id = 1, 
            Name = "SquareWidget", 
            NumberOfTeeth = 6, 
            Color = "Red"
        },
        new Widget() 
        {
            Id = 2, 
            Name = "RoundWidget", 
            NumberOfTeeth = 8, 
            Color = "Blue"
        }
    };

    return View(widgets);
}

One more thing. Modify the Widget Create.cshtml view and add the two new properties:

@model WidgetApplication.Models.Widget
 
@{
    ViewBag.Title = "Create";
}
 
<h2>Create</h2>
 
<script src="@Url.Content("~/Scripts/jquery.validate.min.js")" type="text/javascript"></script>
<script src="@Url.Content("~/Scripts/jquery.validate.unobtrusive.min.js")" type="text/javascript"></script>
 
@using (Html.BeginForm()) {
    @Html.ValidationSummary(true)
    <fieldset>
        <legend>Widget</legend>
 
        <div class="editor-label">
            @Html.LabelFor(model => model.Name)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.Name)
            @Html.ValidationMessageFor(model => model.Name)
        </div>
 
        <div class="editor-label">
            @Html.LabelFor(model => model.NumberOfTeeth)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.NumberOfTeeth)
            @Html.ValidationMessageFor(model => model.NumberOfTeeth)
        </div>
 
        <div class="editor-label">
            @Html.LabelFor(model => model.Color)
        </div>
        <div class="editor-field">
            @Html.EditorFor(model => model.Color)
            @Html.ValidationMessageFor(model => model.Color)
        </div>
 
        <p>
            <input type="submit" value="Create" />
        </p>
    </fieldset>
}
 
<div>
    @Html.ActionLink("Back to List", "Index")
</div>

Ok we're set up with a Widget class that is a little more complicated and lends itself to some basic cross-property validation. For instance let's say that all red widgets are small in size and have teeth no greater than 6. All blue widgets are medium in size and must have between 8 and 12 teeth. Since these two rules involve more than one property of the class this is a perfect candidate for implementing IValidatableObject on the Widget class. The interface is found in System.ComponentModel.DataAnnotations which is convenient since we've already referenced it in our class. IValidatableObject has one method we need to implement:

IEnumerable<ValidationResult> Validate(System.ComponentModel.DataAnnotations.ValidationContext validationContext)

Let's implement it now in our Widget class:

public class Widget : IValidatableObject
{
    private const int MIN_RED_TEETH = 0;
    private const int MAX_RED_TEETH = 6;
    private const int MIN_BLUE_TEETH = 8;
    private const int MAX_BLUE_TEETH = 12;
 
    public int Id { get; set; }
 
    [Required]
    [NameAvailable]
    public string Name { get; set; }
 
    [Required]
    public int NumberOfTeeth { get; set; }
 
    [Required]
    public string Color { get; set; }
 
    public IEnumerable<ValidationResult> Validate(ValidationContext validationContext)
    {
        if (Color.ToUpper().Equals("RED"))
        {
            if (NumberOfTeeth < MIN_RED_TEETH ||
                NumberOfTeeth > MAX_RED_TEETH)
 
                yield return new ValidationResult(
                ValidationMessagesResource.IncorrectRedWidgetToothCount,
                new[] { "NumberOfTeeth" });
        }
 
        if (Color.ToUpper().Equals("BLUE"))
        {
            NumberOfTeeth < MIN_BLUE_TEETH ||
            NumberOfTeeth > MAX_BLUE_TEETH)
            
            yield return new ValidationResult(
                ValidationMessagesResource.IncorrectBlueWidgetToothCount,
                new[] { "NumberOfTeeth" });
        }
    }
}

Well we've put off creating a database long enough. Now we need one because IValidatableObject requires a database context to do its thing. If you installed the the VS 2010 SP1 WebPI Bundle you also installed SQL Server 4.0 Compact Edition. I'm going to use that database because it's quick, easy, and free. Here are the steps:

First hook up the controller to our context. We need our Index method to fetch all widgets in the (soon to be created) database and we need our Create method to write new ones to it:

public ViewResult Index()
{
    return View(db.Widgets.ToList());
}

[HttpPost]
public ActionResult Create(Widget widget)
{
    if (ModelState.IsValid)
    {
        db.Widgets.Add(widget);
        db.SaveChanges();
        return RedirectToAction("Index");  
    }
    return View(widget);
}

Remember the WidgetApplicationContext file we created back with the scaffolder? That's what EF Code First 4.1 will use to create the database. But we have to initialize it so go into your Global.asax and paste this into your Application_Start method:

System.Data.Entity.Database.SetInitializer(new System.Data.Entity.CreateDatabaseIfNotExists<WidgetApplication.Models.WidgetApplicationContext>());

And of course we need to set our connection string in Web.config:

<connectionStrings>
  <add name="WidgetApplicationContext"
        connectionString="data source=|DataDirectory|WidgetDatabase.sdf; Persist Security Info=false;" providerName="System.Data.SqlServerCe.4.0" />
</connectionStrings>

That's it. We've told EF to create a SQL Server 4.0 CE database in our App_Data folder and to use the models in our WidgetApplicationContext to create tables for us automatically. Go ahead and fire up the app and create a new widget called "PurpleWidget" that has 10 teeth and is colored purple (what else?). Notice that EF created our database for us and has inserted the new widget in there. Now let's add some code to our WidgetController Create method to check for class-level validation errors before saving it to the database:

[HttpPost]
public ActionResult Create(Widget widget)
{
    if (ModelState.IsValid)
    {
        var errors = db.GetValidationErrors();
        if (errors.Count() > 0)
        {
            return View(widget);
        }
        db.Widgets.Add(widget);
        db.SaveChanges();
        return RedirectToAction("Index");  
    }
 
    return View(widget);
}

Now's a good time to add a couple of error messages to your string table or just hard-code them in the Validate method. Now build the app and fire it up. Create a new widget called "RedWidget" with 50 teeth and the color Red. Notice how our class-level validation kicks in and your error message displays next to the correct property.

Simple and Custom Validation in MVC 3

Sun, 05 Jun 2011 19:03:00 GMT

This is the first of a series on validation and business rules in MVC 3. I'll start out simple and we'll work out way up to the more complex. I'm going to build on the solution created in the previous blog post (Delete Like a Rock Star) so go there and get set up.

Ok. MVC 3 models (POCOs, classes, whatever) can take advantage of a whole host of validation attributes located in System.ComponentModel.DataAnnotations. Throw the object browser on there and you can see them all. Let's take a basic one. Who doesn't love a required field? Let's put one on our Widget name:

using System;

using System.Collections.Generic;

using System.ComponentModel.DataAnnotations;

using System.Linq;

using System.Web;

using YourSolutionNamespace.Validators;

namespace YourSolutionNamespace.Models

    public class Widget

        public int Id { get; set; }

        [Required]

        public string Name { get; set; }

Notice I'm using System.ComponentModel.DataAnnotations. Before we fire up the app comment out the two lines in the controller's Create method that would ordinarily call EF:

[HttpPost]

public ActionResult Create(Widget widget)

    if (ModelState.IsValid)

        //db.Widgets.Add(widget);

        //db.SaveChanges();

        return RedirectToAction("Index");

    return View(widget);

Now fire up the application, navigate to Widgets, and click the Create new link to be taken to the create new widget view. Try to save it without entering in a value for the name field. You get some nice out-of-the-box behavior. Now let's write a custom validator. Let's say that a new widget name cannot be the same as one already in the system. We'll need a custom validator called NameAvailableAttribute that encapsulates this requirement. Create a new folder called Validators. Then drop this class into the new folder:

public class NameAvailableAttribute : ValidationAttribute

    public override bool IsValid(object value)

        if (value == null)

            return true;

        if ((value is string) && string.IsNullOrEmpty((string)value))

            return true;

        var name = value.ToString().ToLower();

        // fake a database lookup and bring back two widgets

        var widgetNames = new List<Widget>()

            new Widget() { Id = 1, Name = "SquareWidget"},

            new Widget() { Id = 2, Name = "RoundWidget"}

};

        return (!widgetNames.Any(w => w.Name.ToLower().Equals(name)));

    public override string FormatErrorMessage(string name)

        return ValidationMessagesResource.NameIsTaken;

Two things here: I'm not talking to a database but just faking it out (in a future blog post I'll expand on this code). Second, I put an error code in a resource table and from FormatErrorMessage I just call it. You could just as easily hard-code the string here. Call me crazy but I like string tables for this sort of thing.

Now we need to decorate our Name property in the Widget class. Reference the namespace to the new validator and add the new attribute:

[Required]

[NameAvailable]

public string Name { get; set; }

Build and fire up the app and go through the process of creating a new widget again. This time enter something like "Purple Widget" and make sure it behaves correctly. Then enter "SquareWidget" and you should see your custom error message.

That's it for now. Places to go from here are client-side AJAX calls to our custom validators for database lookup scenarios, implementing class-level validation with IValidatableObject, and using Ninject to inject business rules (or services that know how to get them) into your model. These are topics for future blog posts.

Delete Like a Rock Star with MVC3, Ajax and jQuery

Fri, 03 Jun 2011 17:42:00 GMT

Sure you can be a chump and use the out-of-the-box delete functionality that the MvcScaffolding gives you. Or you can use a little jQuery and delete like a rock star. Get your project set up first. Create a new MVC3 web app in Visual Studio 2010. If you have SP1 you have a choice now: internet or intranet. I'll assume we're creating an internet app but it doesn't matter really. Next add a new model called Widget:

public class Widget
{
    public int Id { get; set; }
    public string Name { get; set; }
}

Build the solution. Then right-click on Controllers folder and add a new controller called (what else?) WidgetController. Use the EF template and let the scaffolder do its thing. If your popup doesn't look like mine then you probably don't have SP1 installed:

Your WidgetController will be stubbed out for you. We're going to ignore the DbContext it references because this blog post ain't about EF. Just return a static list of widgets from your Index method:

public ViewResult Index()
{
    var widgets = new List<Widget>
    {
        new Widget() {Id = 1, Name = "Purple Square Widget"},
        new Widget() {Id = 2, Name = "Red Round Widget"},
        new Widget() {Id = 3, Name = "Blue Octagonal Widget"}
    };
    return View(widgets);
}

One last little detail. In your Shared folder edit _Layout.cshtml to add a menu link to the widget page:

<li>@Html.ActionLink("Widgets", "Index", "Widget")</li>

Ok build and run the app. Click on the Widgets tab and you should see your stubbed-out list of three widgets. Now click on the Delete link for one of them. See that postback with the big delete button? Do you really like that behavior? Neither do I. Wouldn't it be cooler to click the Delete link and be able to confirm and delete on the index page without posting back the entire page? That's the real subject of this post. So let's do it. Close your browser and get back into VS 2010.

We're going to use jQuery for some client-side magic so in your _Layout.cshtml page reference two scripts:

jquery-ui-1.8.11.min.js
jquery.unobtrusive-ajax.min.js

Now back at the WidgetController. You can see how the scaffolder created an action method for the GET verb and then another for the eventual POST from the confirmation page. Go ahead and comment out both of those methods and add this one:

[AcceptVerbs(HttpVerbs.Post)]
public JsonResult Delete(int id)
{
    // let's just pretend we deleted it from the database
    var message = string.Format("Deleted Id '{0}' from the database!", id);
    return Json(new
    {
        id = id,
        message = message
    });
}

Two things. I changed the return type to a JsonResult and I added a POST verb attribute to the method as a matter of best practice.

Ok now go to your Widget Index.cshtml page. We want to do four things here. First, put a span tag above the table for a confirmation message. Second, change the Delete ActionLink to an Ajax call. Third, add a javascript function to handle the Ajax success callback. Finally, put some class names on the table so we can refer to them later. Rather than waste your time and mine let me just show the entire Index.cshtml page with all four of these changes:

@model IEnumerable<WidgetApplication.Models.Widget>
 
@{
    ViewBag.Title = "Index";
}
 
<h2>Index</h2>
 
<p>
    @Html.ActionLink("Create New", "Create")
</p>
 
<span id="actionMessage"></span>
 
<table class="widgets">
    <tr>
        <th>
            Name
        </th>
        <th></th>
    </tr>
 
@foreach (var item in Model)
 {
     <tr id="widget-id-@item.Id">
        <td>
            @Html.DisplayFor(modelItem => item.Name)
        </td>
        <td>
            @Html.ActionLink("Edit", "Edit", new {id = item.Id}) |
            @Html.ActionLink("Details", "Details", new {id = item.Id}) |
            @Ajax.ActionLink("Delete", "Delete", "Widget",
                new {id = item.Id},
                new AjaxOptions {
                    HttpMethod = "POST",
                    Confirm = "Are you sure you want to delete this widget?",
                    OnSuccess = "deleteConfirmation"
                })
        </td>
    </tr>
}
 
</table>
 
<script type="text/javascript">
 
    function deleteConfirmation(response, status, data) {
 
        // remove the row from the table
        var rowId = "#widget-id-" + response.id;
        $('.widgets').find(rowId).remove();
 
        // display a status message with highlight
        $('#actionMessage').text(response.message);
        $('#actionMessage').effect("highlight", {}, 3000);
    }
    
</script>

See how the old delete ActionLink is now replaced with an Ajax action link? It's a little more verbose but not too bad. You have to tell it the controller name following the MVC convention. And there's a new AJaxOptions parameter with three settings: (1) HttpMethod to force a POST to the server; (2) Confirm to require client-side confirmation as a condition of the AJax post; and (3) OnSuccess to define a javascript callback function when we have a response.

The jQuery magic is in that deleteConfirmation javascript function. Since the widget was deleted successfully server-side we need to remove it from the table. Since our table rows have a unique id on them we can find the exact tr tag and remove it from the table. That's a lot more elegant than calling a window.location.reload() or redirecting to the Index page again like the scaffolder does. We removed the table row but that might be a bit sudden for our end users. So we put a message in the actionMessage span tag and give it a highlight effect for 3 seconds so it catches their eye and gives them a warm fuzzy that everything is ok.

Time to run it? Go for it. Now delete a row or two and relish in the awesomeness that jQuery gives us. And our code changes weren't all that complex either. Enjoy.