MVVM on MVC: HTML is not XAML

I have to admit that I may have rolled my eyes a bit when I first learned about the KnockoutJS library. It sounded too much like forcing a square peg into a round hole. Isn’t Model-View-Controller (MVC) already it’s own pattern? Does it make sense to apply something like Model-View-ViewModel (MVVM) to HTML? I already had enough issues dealing with MVVM on the platform it was designed for, XAML and C# (WPF and Silverlight). Some people simply didn’t get the pattern, others were pushing it without really understanding its benefits, and many applications completely and unnecessarily overcomplicated their implementation of the pattern. So before we talk about whether it makes sense in HTML-based applications, we first need to agree on what the benefits of the pattern are.

I’ve heard many opinions regarding this and have not only read lists, but also published my own. You might hear things like “decoupled code” or “best practices” or “modularity.” Many of the benefits often cited are really just good coding practices that should be implemented regardless of the user interface (UI) pattern being followed. After looking at all of the different benefits, coding using different patterns, and spending several years building enterprise Line of Business (LOB) Silverlight applications it really boils down to two specific benefits:

1. Testability – MVVM improves the testability of your application. This is only a benefit if you feel that testing itself provides benefits.
2. Designer-Developer Workflow – MVVM facilitates a separation of UI and presentation logic concerns from the business layer that makes it easy to streamline the development process by allowing design cycles to happen in parallel with development. A great example of this was the Microsoft Looking Glass project that had more than 6 designers working on design for over 3 months while we developed it. The total delivery time was around 4 months, instead of the typical 7 (3 + 3 + 1 month of testing) you get when the design process has to happen sequentially and not parallel to the development effort.

The design-time views even without the workflow are useful but not critical in my opinion. So how does this all translate to HTML-based development?

HTML is Not XAML

The first distinction that Silverlight and WPF developers need to make is between HTML and XAML. They are often compared, but are they really similar?

XAML is a declarative language for instantiating an object graph. While it is commonly used for UI elements, it can create special objects like styles that apply theming to elements, behaviors, triggers, even code that has no visual artifacts whatsoever. XAML by nature is extensible. You can create new elements that map to custom classes, and extend the attributes of existing elements through attachments and custom markup extensions. This strict relationship between the declaration and the object graph means that invalid XAML is a Bad Thing™ and causes the XAML parser to choke. If it cannot instantiate an object or set a property, the entire visual tree is invalid and that’s that.

HTML is declarative markup. It defines a structure. Most of that structure is simply containers for information. There is minimal behavior. Elements are pre-defined based on an accepted standard and arbitrary extension or customization is not supported. The containers provide some structure to information, but it is ultimately CSS that defines the UI and to an extent some of the presentation logic and behaviors. JavaScript handles the object graph for the page, but neither CSS nor HTML declaratively instantiate JavaScript objects. It’s the other way around – JavaScript in the context of a page is more like parsing an XML Document in C# code than it is like having XAML and code-behind. The closest thing to XAML in the web world is server-side code that through whatever mechanism emits the HTML and JavaScript code elements of a web page.

Because HTML is just structure, browsers can also be very forgiving in their parsing. They do not have to map an element to an actual class or type that is instantiated. Browsers will close your tags for you and even make substitutions for elements they don’t recognize. There are well-known algorithms for rendering HTML.

So how does this fit into MVC? First, let’s be clear on one important distinction:

MVC as a Framework, not a Pattern

Note I didn’t say MVC is a framework, but in the context of this conversation we’ll have to agree that I’m referring to MVC as a Microsoft Framework and not the pattern. When you talk about the pattern, it can get very confusing when introducing an entirely separate pattern like MVVM. When you talk about a framework based on the pattern, it’s a little easier to understand. While ASP. NET MVC is based on the MVC pattern, it doesn’t force a strict implementation or interpretation of the pattern and provides quite a bit of flexibility with how you structure your pages. You can choose different view engines and write your code in different languages.

So what about MVVM in the MVC framework? One of the key problems I’ve found when dealing with MVC is markup that looks like this:

<div id="logoDisplay">                
   <% Html.RenderPartial("LogoControl"); %>            
</div>                      
<div id="menuContainer">
   <ul id="menu">
      <li><%: Html.ActionLink("Home", "Index", "Home")%></li>
      <li><%: Html.ActionLink("About", "About", "Home")%></li>
   </ul>                       
</div>

What’s wrong with this? It compiles and runs perfectly fine, right? Here’s my issue: I’ve just lost my designer-developer workflow. True, I might be able to hire an MVC-savvy designer who can work with this code, or I may be responsible for design myself. I’ve seen this workflow before:

1. Designer creates Adobe Photoshop assets
2. Same designer or someone else turns it into a beautiful HTML web page
3. Developer has to rip out the HTML as best as they can and format it into the view and merge into CSS
4. QA tester finds some strange nuance where a field wraps and unfortunately the designer doesn’t know how to fix it because their version works fine, it’s only in the runtime that it happens
5. It turns out one of the embedded commands emitted some whitespace that the template didn’t account for and was causing the issue
6. etc. etc. etc.

This also gives me no design-time experience. If HTML was real HTML without any embedded markup, I could just drag it into a browser and go to town. This is one place I start to see value with MVVM in MVC. I could do the same thing above, but make it look like this instead:

<div id="menuContainer">
   <ul id="menu">
      <li data-bind="foreach: menuItem">
         <span data-bind="text: name">Name</span>
      </li>     
   </ul>   
</div>

Now I’ve got clean HTML that I can hand to a designer. I can even pull it up in a browser and view it to get a preview. Only … there’s still a problem. Can you see it?

The Problem with Data-Bind

Remember how I mentioned that HTML is not XAML? HTML is not supposed to be arbitrarily extended as in the previous example. In fact, most editors will complain about the data-bind attribute because it’s not a valid, defined attribute. Sure, you’ll get away with it: browsers are notoriously forgiving when it comes to bad mark-up, but this is what I would call an invasive or intrusive way to mark up HTML. What would really be nice is if we could do this more cleanly and provide pristine HTML with CSS, then provide our behaviors, validations, etc. in a way that is design-time friendly and testable.

A Clean Approach

For my “clean” approach I decided to model a simple form. It allows for first name and last name, shows the name dynamically as it is edited, and only allows submission when both fields are entered. First, let’s take a look at the HTML. I’m confident I could pass this off to a designer and they could modify it to their heart’s content. The only requirement is that they honor my “contract” which is the specific ids I’ve assigned. We agree there is something called a first name and last name and that they should be consistently referenced as firstName and lastName – whatever else they want to change is up to them.

The full HTML is here:

<!DOCTYPE html>
<html lang="en">
   <head>
      <title>Example MVVM Form</title>
      <link rel="stylesheet" href="style.css" type="text/css" media="screen" />
      <script type="text/javascript" language="javascript" src="jquery-1.7.1.js"></script>
      <script type="text/javascript" language="javascript" src="knockout-2.0.0.js"></script>
   </head>
   <body>
      <h1>Example MVVM Form</h1>
      <p>This is an example of an MVVM-based form. The HTML is "clean" markup - there are no custom attributes, tags, or embedded JavaScript. Everything is wired separately through code.</p>
      <form id="mainForm" action="#">
         <div class="form-label">Full Name:</div>
         <div class="form-field"><span id="fullName"></span>&nbsp;</div>
         <div class="form-label">First Name:</div>
            <div class="form-field">
               <input id="firstName" class="textField" type="text"/>
               <span id="firstNameValidation" class="field-validation"></span>
            </div>
         </div>
         <div class="form-label">Last Name:</div>
            <div class="form-field">
               <input id="lastName" class="textField" type="text"/>
               <span id="lastNameValidation" class="field-validation"></span>
            </div>
         </div>
         <input type="submit" class="formButton" value="Save">
      </form>
      <script type="text/javascript" language="javascript" src="./viewModel.js"></script>
      <script type="text/javascript" language="javascript" src="./mvvm.validations.js"></script>
      <script type="text/javascript" language="javascript" src="./bindings.js"></script>
   </body>
</html>

Now that we have a page we can easily edit, let’s make it a little prettier with some simple CSS:

body {
    font-family: arial, helvetica, sans serif;
}

h1 {
   color: maroon; font-size: 20pt; font-weight: bold;
}
p {
   font-size: 12pt; 
}
.form-label {
   font-weight: bold;
   float: left;
   width: 200px;
   padding: 10px; 
}
.form-field {
   padding: 10px;
}
input.textField {
   width: 300px;
}
input.formButton {
   width: 100px;
   background-color: lightgreen;
   border: 2px solid green;
}
input.formButton:hover {
   background-color: lightred;
   border: 2px solid red;
}
.field-validation {
   font-weight: bold;
   padding-left: 10px;
   color: red;
}

The view model is easy enough, it simply defines fields for the first and last names and a computed field that shows the full name. I’ve even been kind enough to humbly supply a default first name:

function NameViewModel() {

   var self = this;

   this.firstName = ko.observable('Jeremy');
   this.lastName = ko.observable('');

   this.fullName = ko.computed(function() {
      if (self.lastName()) {
         if (self.firstName()) {
            return self.lastName() + ', ' + self.firstName();
         }
         return self.lastName();
      }
      return self.firstName();
   });
}

var viewModel = new NameViewModel();

What’s nice about the MVVM approach is that I can easily extend the view model to provide validation. I will eventually use the JavaScript module pattern to create the validations so they can be easily attached and extended, but for this simple example I just used a simple object instead. In this case there is simply a required validation. In a full production system, I would have a library of these validations and also keep a collection on the target object to allow multiple validations to attach to the same attribute.

ko.extenders.required = function (target, overrideMessage) {
    
    target.hasError = ko.observable();
    target.validationMessage = ko.observable();

    function validate(newValue) {
        target.hasError(newValue ? false : true);
        target.validationMessage(newValue ? "" : 
             overrideMessage || "This field is required.");
    }

    validate(target());
    target.subscribe(validate);
    return target;
};

function MvvmValidations() {
    
    this.required = function(target, overrideMessage) {
        target.extend({ required: overrideMessage });
    };

}

Now I have a view model specific to my view and a validation library that I can reuse across multiple views. I tie them all to the HTML like this – note that what is important is that the contracts were honored for the identifiers of the various elements, but everything else can be simply attached and declared.

$(document).ready(function() {

   $('#firstName').attr('data-bind','value: firstName, valueUpdate: "afterkeydown"');
   $('#lastName').attr('data-bind','value: lastName, valueUpdate: "afterkeydown"');
   $('#fullName').attr('data-bind', 'text: fullName');
 
   var validations = new MvvmValidations();

   validations.required(viewModel.firstName);
   $('#firstNameValidation')
   .attr('data-bind','visible: firstName.hasError, text: firstName.validationMessage');

   validations.required(viewModel.lastName, "Last name is required."); 
   $('#lastNameValidation')
   .attr('data-bind','visible: lastName.hasError, text: lastName.validationMessage');

   viewModel.saveName = function() {
      if (viewModel.firstName.hasError() || viewModel.lastName.hasError()) {
         alert('Errors exist.'); 
         return false;
      }
      alert('Looks good!');
      return true;
   };

   $('form').attr('data-bind', 'submit: saveName'); 
 
   ko.applyBindings(viewModel);

});

You can view the end result and download the source here: http://apps.jeremylikness.com/samples/knockout-mvvm/mvvm.html

Quod Erat Demonstrandum

So what have we achieved? I think quite a bit. This format has allowed me to build out a website using data-binding. The source HTML is clean and can be edited easily by a designer. While I muck around with the DOM at runtime, this is done programmatically and doesn’t require that I invade the HTML or CSS. The JavaScript is separate, reusable, and testable.

The thing I haven’t shown is how this fits into the MVC framework. In the framework you’ll likely go ahead and use some of those helper methods to specify the path to the JavaScript but you should be able to maintain a nice, clean HTML core. And if the view models seem like a lot of work, you’re not thinking about the bigger picture. With a strongly-typed view (one that correlates to a typed model) you can easily create a view helper that emits the necessary JavaScript for the view model. You could probably even emit the code to generate the bindings, and the only step you would need to take as a developer would be to write the controller to return the model and apply any validates specific to the view.

At the end of the day, I’m a believer that MVVM can work in MVC if we remember that HTML is not XAML and approach the code the right way.

Video: Getting Started with Jounce MVVM and MEF for Silverlight 5

I created a quick video to help you get started with using Jounce. The video starts with a blank slate, steps through installation of Jounce and the creation of a sample view model for a simple contact record that includes validation.

You can access the video directly at http://vimeo.com/jeremylikness/jounce-getting-started, or view it below:

Jounce: Getting Started from Jeremy Likness on Vimeo.

Jounce 2.0 MVVM with MEF for Silverlight 5 Released

I'm pleased to announce the official release of Jounce 2.0 for Silverlight 5. There are quite a number of new features available that I'll review in this post. Most significantly, of course, the code base has been updated specifically to target Silverlight 5. A number of bug fixes, feature requests, and Silverlight 5 features have been added. The DLL for Jounce is still just under 100 KB for release so it remains nimble and lightweight.

There are two ways you can install the latest. Zip over to Jounce at CodePlex to download the binaries and/or the full source. Or, jump into NuGet and install the Jounce package. The package is set up to wire in a default application. To get this functionality, follow these simple steps:

1. Create a new Silverlight application. I recommend the basic "Silverlight Application" template as I haven't tested with any others, and it doesn't matter if you host it in a web site and/or choose to use WCF RIA services.
2. Delete the App.xaml and MainPage.xaml files. Trust me on this one.
3. Jump into the package manager console and type Install-Package Jounce.
4. Hold down CTRL and press F5 and you should see a welcome message. That's it. You are ready to write your Jounce application.

What's New

The code base is now CLS compliant.

The application service used to wire Jounce now exposes some configuration properties. You can use this to have Jounce ignore unhandled exceptions (by default, it will intercept these and publish them as a message instead) and also to set the debug level. These used to be parsed from the parameters from the object tag but obviously this did not make sense for OOB applications.

When dynamically loading XAP files (i.e. extension or plugin modules) you can specify a callback that Jounce will call to report progress. This allows you to have more control over the extension points and display a progress message to the end user for example.

The processing of the XAP file URL was updated to allow query strings. This is a common method to dynamically serve up XAP files and/or to manage updates for OOB applications. Jounce used to choke on this but the code was updated to gracefully handle this when you specify the URL to the XAP to download.

You no longer have to derive your view model from the BaseViewModel class. The only requirement for the framework to work is for you to implement the IViewModel interface. This will help developers who wanted to provide their own base class services and found it difficult due to the face you cannot derive from more than one base class (hey, I managed to sneak in a basic interview question).

You can specify an option using metadata to automatically call Deactivate on your view model when the corresponding view is unloaded (i.e. if the Unloaded event fires). This allows you to perform clean up automatically when the view goes out of scope.

You can now map a view to a view model in three ways. You can export a ViewModelRoute, you can fluently bind them using a new interface, and you can specify the view model in XAML. The new MapToViewModel custom markup extension allows you to specify the view model name, whether you want a shared or non-shared copy, and whether the Deactivate method should be called when the view is unloaded. This makes it possible to use templates that bind to new instances of view models.

There is additional support for the OOB windows. You can append parameters to the navigation payload or use some fluent extension methods to specify the title and size of a view and have it loaded into a separate window instead of a region. You can also raise events with a title to set the title of the HTML page (in browser) or OOB application (out of browser). To further support OOB, there are additional attributes you can query on the base view model to determine if the application is running out of browser and whether or not it is installed on the user machine.

There is a new class available called CustomType that allows you to construct a dynamic type that is bindable to view models. For example, you might parse a JSON object and use this type to build up the object. It features methods to add new properties and fetch them and will also act as a dictionary with an indexer. It uses an underlying helper class that takes advantage of Silverlight 5's ICustomTypeProvider. You can use the source as a template to build your own custom types (or derive from it instead).

I will update documentation and examples as I can moving forward. My book, Designing Silverlight Business Applications, has many examples of building applications using Jounce including WCF RIA. Thanks everyone for their patience and support of this project!

CRUD it’s now CQRS … or is it?

In 1983 author James Martin published a book called Managing the Data-Base Environment. It’s interesting the term database is hyphenated in the title; it hadn’t quite settled down as a mainstream term yet. I have not read this book myself, but my understanding is that he presented the concept of the “CRUD Matrix” for engineering how an application performs Create, Read, Update, and Delete operations against the database. Regardless of how the term was first coined, it has gained popularity and is in widespread use today.

CRUD is a model that has existed for decades. A large number of software systems can be classified as a simple combination of CRUD + validation. This is why so many scaffold frameworks provide nearly the same pattern: list records, select record, view detail, edit or delete, and validate a bit along the way. If you are working on an application that follows the pattern of view data, pull it in, do stuff with it, then push it back out, you have an amazing number of options to build it quickly and easily with little ritual or ceremony involved. I see this approach quite often in the development of consumer-facing applications. One track focuses on the engine to present the content to the consumer while the backend system to configure and set up content is quickly generated using a data-driven tool.

If all software operated in CRUD mode many of us might not be employed because it would be so easy to pull CRUD instances out of the assembly line. Software can be quite complex, however, and often models more complex business processes that introduce workflows and state machines that aren’t easily captured with the traditional CRUD model. This fact has led to movements like DDD or Domain-Driven Design, which according to the community website is not a framework or technology but a “way of thinking and a set of priorities.” You focus on the business model and domain, paying attention to important details such as having a common vocabulary that everyone can use to describe the requirements without ambiguity. The source for this concept is defined in the popular “blue book” by Eric Evans called Domain-Driven Design.

A set of new patterns for manipulating data has also emerged to challenge the traditional CRUD model. You can go back to Bertrand Meyer’s Command Query Separation and then examine more recent Command Query Responsibility Segregation (CQRS) pattern by Greg Young to start digging into these principles. A number of implementations exist, including the concept of Event Sourcing. All of these are great patterns to learn and understand as part of your software development toolbox.

While the paradigm shift away from traditional CRUD approaches is refreshing, it can also be problematic. There is always the risk of falling victim to the “flavor of the day.” When I began building Silverlight applications, I was reluctant to fully embrace the MVVM pattern because it was consistently hyped as “the way to go” without very much substance around why it was the way to go. I kept sorting through the catchy phrases like “decoupled code” and “SOLID principles” trying to find the value and bottom line for using this pattern, but it wasn’t until I implemented it myself and observed it in practice through several projects that I was able to finally decide it made sense. My teams were able to develop software faster through parallel workflows and the fact that I could engage an entire design team at the same time I was building the application rather than forcing the project into a sequential workflow was the real benefit I found in addition to the support for testing.

I’ve watched a similar trend with CQRS. Like MVVM, many people are declaring it “too complex” when in fact a proper implementation can be quite simple. Just like the MVVM cops appeared one day and starting writing tickets when developers didn’t completely eliminate their code-behind files, I see some CQRS police saying “if you’re not doing it this way, it’s not CQRS.” In many cases that may be correct, but I think it also undermines the spirit of the pattern. In some cases the pure implementation is exactly what is needed … but is it a new rule that everything must go this route?

I think you’ll find the strongest proponents and advocates for the pattern will be the first to say you should use the right tool for the right job. In my book about designing LOB Silverlight applications I added a controller class to an application that is mostly based on the MVVM model. I also include examples with logic in the code-behind. To some this may seem like sacrilege but in fact these cases were the right tool for the right job: they solved the problem while keeping it simple without compromising the ability to test the application.

I learned about the danger of “either-or” thinking back when I was a personal trainer and had an online coaching practice. I found many clients would get stuck in the either-or mentality. For example, “either I completely eliminate soda or my diet is blown.” Rather than, say, cutting back to just one glass a day for awhile. When traveling, I’d hear, “I can’t get my steamed chicken breast and broccoli so I’m just going to get a big pile of junk from a fast food restaurant” instead of looking for healthier options. “The only thing we had to eat was pizza.” Well, sometimes that happens – but instead of eating fifteen slices, why not just eat one? When I taught clients it is okay to compromise – if your workout calls for free weights but your hotel only has dumbbells, go ahead and train with what you have and get a workout done rather than using it as an excuse to sit in the hot tub for an hour – they had tremendous breakthroughs and were able to achieve a true lifestyle change rather than getting stuck in a diet cycle that was doomed to fail and send them back into old habits.

What does this have to do with software? I think quite a bit. You don’t have to take an either-or approach to building applications, either. For example, it’s not a question of using the entire Prism library or Enterprise Library in an application. It’s perfectly valid to pull out the parts you need – maybe the command implementation from Prism and the logging application block from the Enterprise Library – without overcomplicating the project. When you are looking at patterns, it’s fine to create something that is a hybrid if it fits the needs of your application.

Back to CQRS. I think Microsoft has provided some incredible tools for exposing data as services. With the combination of the Entity Framework and WCF Data Services I can create a set of REST-based services within minutes that are consumable by Silverlight, Windows 8 applications, iPads, iPhones, Windows Phones, RIM devices and Android phones and tablets. It’s just that easy. Unfortunately, while the tools also support CRUD operations (and even provide places you can hook into for validation) it doesn’t always integrate well with a domain-driven approach to the application design. That means it’s off the table, right? CQRS is about having different databases, right?

I’d say, “Wrong” on both counts. If the model works well for querying data, configure it to allow queries and get your read operations up and running in minutes. Sometimes over 80% of your application may be about querying and displaying data, so why not keep it simple and expose it in a way that is easy to expand to other platforms when and if needed?

But what about updates?

The updates don’t have to follow the same set of interfaces if you don’t want them to. It’s perfectly valid to expose a REST interface or even a RPC-based interface that takes commands rather than “update operations.” Why not? You may have a workflow engine backed by state machines and queues that implement Event Sourcing, and that still doesn’t mean you can’t expose the read interface for your data using WCF Data Services out of the box.

My point is that CQRS provides what I think is a very valuable insight: that how you read and query data is probably very different from how you manage, update, and manipulate data. You don’t have to have a picture-perfect implementation of CQRS to take advantage of this concept – it may be as simple as looking at a different set of interfaces and implementing them using different technologies in the stack. I’ve built implementations based on this philosophy that still have one database and one data model using the Entity Framework but provide multiple implementation paths. They allow me to quickly and easily update the model while keeping the code simple and easy to both understand and maintain.

There are some exciting new patterns and approaches to building software that developers should be aware of, but it’s important to look at these as new tools, not new toolboxes. During decades of enterprise software development I’ve rarely watched the toolbox change – it’s almost always been about adding new tools and throwing old ones out. I still see applications that will benefit from the traditional CRUD model and get overly complicated when someone tries to force them into something different. To make a long blog post short: patterns should not be used to define your software, but rather to help solve the problems your software addresses.