Steve Smith's Blog

Principle of Least Surprise

ssmith — Thu, 09 Jul 2009 14:57:49 GMT

When developing software, and especially when building user interfaces, it’s a good idea not to surprise the end user. This is known as the Principle of Least Surprise (or Astonishment if you want to go for maximum drama). It may seem obvious, but in practice it’s often easier said than done. This is why user interfaces are often difficult to work with, especially if they’re built according to how the programmers think about the system with no input from actual users.

For example, in a data entry scenario where some data entered could cause an inconsistency with other data in the system, there are several options one might consider. To make this more concrete, let’s say that you can have an ad campaign spanning some time period, and within this you have individual advertisements, each with its own time period. There is an overall business rule that the campaign time period defines the ultimate boundaries of the advertisements’ periods (start and end dates).

Now, on form where the user can edit the campaign’s dates, you have to decide what to do if they change a date such that advertisements’ dates are now out of bounds. For example, the campaign’s start date was 15 July 09 and its end date was 15 August 09, and within it is an advertisement A that runs from 15 July 09 to 15 August 09 and another advertisement B that runs from 20 July 09 to 27 July 09. The user needs to update the campaign so that it starts on 16 July 09.

Some options:

Always set all advertisements’ dates to the new campaign dates
Throw a validation error and do not allow the user to save dates that would cause the advertisements’ dates to be invalid
Warn the user that advertisement dates are now out of range, and let them click a button to adjust them to be the new campaign dates.
Do nothing – let the new dates be set.
Allow the update to go through but set a status flag on the campaign to show that it is now in an invalid state (and hope the user corrects this)
Same as 5, but the update isn’t actually saved, but rather the campaign and advertisements are saved to a sandbox while their state is invalid, and the user is made aware that until the business rules are met, the whole campaign cannot be saved. The user can continue editing the sandboxed version of the campaign and its advertisements until the dates meet the criteria, and then the whole batch can be saved as one transactional unit of work.

There are certainly other options as well, but these are a good start for analysis purposes.

The first option is the simplest, and ensures that no invalid state can exist from changing campaign dates, because the advertisement dates will always be reset to match the campaign dates. However, unless the user expects this to be the behavior, they’re very likely going to be surprised to find out that when they thought they were editing campaign settings they were in fact editing all of the advertisements’ settings as well. And in this case, advertisement B which clearly was meant to run for a particular 7-day period within the campaign will now have its date range reset to match the full campaign length, which is almost certainly not what the user expects.

Option 2 is good from a PoLS standpoint, because the system doesn’t do anything that the user wasn’t expecting. Unfortunately, the system doesn’t do anything useful, either. If the user really wants to reset the campaign dates, they’re going to be stumped as to how to do it, and eventually might figure out that they need to edit each individual advertisement’s start date before they’ll be allowed to edit the campaign’s start date. Hardly a good user experience, but at least the system has protected them from causing the system to enter an invalid state.

Option 3 is excellent from a PoLS standpoint, because it informs the user of the possible issue but still lets the user accomplish the task they’ve set out to do. And it offers the them a time-saving option to set the dates on the advertisements to match the campaign, which is probably often what the user wants to do, but unlike in option 1 this behavior is now explicit and thus will not come as a surprise to the user or occur when they don’t wish it to.

Option 4 doesn’t immediately surprise the user, but is really one of the worst options because of its insidious nature. Allowing the data to become inconsistent will surprise the user at a later date if they were expecting the system to ensure that the business rules were being maintained. At some future date, when it’s discovered that the dates of the advertisements fall outside the dates of the campaign, and some unexpected system behavior results, the user is going to be puzzled as to how this could have been allowed to happen. PoLS failure.

Option 5 alone is quite reasonable from a PoLS standpoint, but could still allow inconsistent data to be saved into the production system, with the same ultimate consequences as Option 4.

Option 6 seems like the best solution. The user is made aware of the issues but is allowed to continue to make changes to the whole system (campaign + advertisements in this case) until they are in a consistent, valid state. Only then can the changes be committed to the production data store. This is an example of the Unit of Work pattern, and unlike most web-based applications that commit work with each request, this might require the transaction to be maintained across multiple requests before ultimately being committed to the database. No magic happens behind the scenes that the user didn’t expect, and no future consequences occur that the user doesn’t expect, either. And, bonus!, the user can actually get their job done unlike option 2 which is the usual naive approach to trying to prevent the user from hurting themselves.

A related acronym to the PoLS is Do What I Mean (DWIM), which describes users’ feelings when the program they’re using does exactly what they told it to, according to its specification, but not what the user expected. The best user interfaces ensure that the user is always able to find what they need where they expect it, and when they issue commands they do what the user meant for them to do.

As a developer, even when you’re not working on user interfaces, remember that the Principle of Least Surprise (and DWIM) apply to every class and every method you create. Expecially if you’re writing a framework or an API! Try to avoid unexpected side effects in your methods, and if they must be there, ensure that the method name makes clear that they’re happening. If MarkOrderAsCancelled() also deletes all of the OrderDetail records, consider renaming it to something like CancelOrderAndDeleteDetails(), for example. And if a class has insidious dependencies, try to make this more apparent by injecting them via the constructor so users of the class are explicitly aware of them. Writing software that intuitively does what’s expected, from the UI down to the individual methods, is seriously challenging but is something we as software developers should strive for every day.

Silverlight Contest

ssmith — Wed, 08 Jul 2009 14:21:56 GMT

ComponentArt recently announced their Summer Silverlight Coding Competition, running June 22nd to September 22nd this summer. Already there are a bunch of submissions to the contest, although there’s still lots of time left before the contest is over. The winner will be determined based on the results of community voting combined with a panel of judges, so you can help decide which of these apps deserves to win the huge $10,000 prize for being the best application.

Check out the list of contestants and their apps here. Some of the applications submitted so far include collaborative whiteboarding/teaching applications, games, virtual in-browser operating systems, and online stores. Find out what kinds of cool applications others are building in Silverlight and submit your own for a chance to win.

Excel 2007 Named Ranges and Data Validation

ssmith — Tue, 23 Jun 2009 19:41:00 GMT

It’s hard to find information on Excel Named Ranges for Excel 2007 using a search engine. The problem isn’t that there’s no information available, but rather that most of it refers to older versions of Excel. And of course, that would be fine, if Excel 2007 didn’t go and move everything around and add that darned Ribbon thing to make it impossible to find anything. But I digress.

Today I’m working on something in Excel and I want to be able to limit the available values the user can enter into a cell. Should be pretty easy, but I’m having a hard time finding how to do it and it’s been like 5 years since I had to do this so I’m searching for help. Of course, I’m probably not searching for the right terms when I say something like “limit column values excel” and get back a bunch of junk related to the maximum number of columns excel supports.

Once I remembered that these things are called Named Ranges I started to make some progress. What I basically wanted to do was let the user either type in or specify from a drop down list the values that were valid for the cell. It turns out that this is pretty easy to do by specifying a Named Range as the source of a List in the Data Validation. There are a few related tasks here, so let’s cover them one by one.

Define a Named Range
Limit Valid Entries In a Cell to a List of Values
Delete and Manage Named Ranges

Defining a Named Range in Excel 2007

This is actually very easy, and allows you to later refer to the range by name rather than using its $A2:A17 nomenclature. For example, let’s say that you want to limit the Company Names listed in an Excel file to a particular collection of names (e.g. your customers). First, you probably want to put this list into a separate worksheet (which I’ll call Lookup) under a heading that describes the range. The following diagram shows an example:

In this screenshot, I’ve highlighted the Customer Names as well as the actual rows of data, but be careful not to do this when you’re defining your Named Range (go ahead, ask me how I know not to do this… or go ahead and do it and you’ll understand why the third part of this post is on deleting named ranges).

So, highlight just the values you want in your named range. Then click on the white space just above the A column (where it says B2 in my screenshot above). This is called the Name Box. Type in the name for your range. It has to be just one word, no spaces. Let’s call mine CustomerNames, as shown below:

You’ve just defined a Named Range in Excel 2007.

Limit Valid Entries In a Cell to a List of Values

Now switch to your main worksheet (using the tabs at the bottom of the Workbook) which might look like this:

Note that in this example I’ve been entering in customer names by hand, with some duplication. If later on I decide to change Contoso to Contoso, Inc. and then I want to run some reports or show a pie chart displaying sales by customer, these will no longer be grouped together. It’s much better to use a named range to define the list of possible values (and of course this might ultimately come from a database or web service) than to have a lot of manually entered data that could be slightly off.

In Excel 2007, if you want to limit the values a particular cell can have, you should click on the cell (or range) and select the Data tab in the ribbon. Then click on the Data Validation button, which will bring up the dialog shown here:

By default, cells can contain any value (no validation). In this case, we want to change this to use a list of values, so in the Allow drop down list, choose List. Then in the Source: field, put in ‘=CompanyNames’ replacing ‘CompanyNames’ with the name of your Named Range. Click OK.

You can apply the Data Filter to the whole column – it will ignore any headers that currently don’t match (though you’ll be able to use the dropdown on these as well later should you wish to, or simply remove the validation from the header row manually afterward). Now to add a new row, you can click on the dropdown arrow or start typing and get autocompletion of the data, like so:

Delete and Manage Named Ranges

Now let’s say you accidentally create a Named Range that contains more cells than you would like, or that isn’t named what you’d like. You might think that you could redefine that range by highlighting a selection of cells and retyping that name into the Name Box. But no, that doesn’t work. Fortunately, there’s a very easy way in Excel 2007 to manage all of your Named Ranges once you know where to look for it (and no, it’s nowhere in the Data Validation section where thus far we’ve been working with Named Ranges). The trick is to go to the Formula tab on the Ribbon (because frequently Named Ranges are used in Formulas, I suppose). There you will find a Defined Names section which includes a Name Manager. The Name Manager, as you might guess, makes it quite easy to add, edit, and delete Named Ranges from within Excel 2007.

Summary

Named Ranges are a handy feature in Excel. Finding out how to work with them in Excel 2007 if you’re familiar with Excel 2003 or earlier can be a challenge. With any luck, this post will help a few folks out or at least serve to remind me how to do this the next time I need to remember it.

Silverlight 3 on XBox 360

ssmith — Tue, 23 Jun 2009 19:18:27 GMT

Scott Guthrie earlier today twittered about a sneak peek shown today of Silverlight 3 running on an XBox 360. I’ve been waiting a long time for this and I really hope that the XBox platform will be able to take advantage of some of the opportunities that Silverlight has to offer. I’d really like to see the XBox opened up into a more flexible app server, as well as having access to the rich variety of online games that Silverlight already offers. It’s a definite win.

INVESTing in User Stories

ssmith — Mon, 22 Jun 2009 18:00:13 GMT

User Stories describe features from the standpoint of the user, and should identify small units of work that can reasonably achieved within a short (1 or 2 week) iteration by a programming pair. A useful acronym for remembering how to write good user stories is INVEST (more elsewhere and here). A “good” user story is one that serves the needs of all of the stakeholders in the software development project, including the customer, the team lead (or PM), and the developer(s). Ideally the story is recorded in short form on an index card (or electronic equivalent) and is a placeholder for a longer conversation that has taken place between the customer and the developer team. Also ideally, it includes Acceptance Test criteria, which developers must ensure have been met before they consider the story complete.

The INVEST acronym for User Stories

User stories should be…

Independent – In order to be estimated and planned effectively, user stories should be independent of one another. Combining or splitting stories, and also working on vertical slices, are good ways to achieve this.

Negotiable – The precise details of the story are open to further discussion and clarification. Having too much detail in the story can limit options. Developers should be encouraged to fill in necessary details with customer conversations (of course this works best with a local customer or customer proxy).

Valuable – Every story needs to add business value to the customer. Ideally, customers are the ones writing the user stories, to ensure they are deciding what is most valuable to work on. A user story should contribute to a minimal marketable feature (MMF), either in itself or in combination with several other related stories.

Estimable – The story needs to be small enough and well enough understood that developers can estimate the resources required to achieve it. The larger and less well-understood the story, the more difficult it will be to accurately estimate. Achieving this is usually done by discussing the problem further with the customer (increase domain knowledge), performing a spike (increase technical knowledge), breaking up the story into smaller pieces (small stories are easier to estimate), or some combination of these three tactics.

Small – Large stories are difficult to estimate and tend to include dependencies and hidden subtasks that can quickly scope creep them into massive epics. Stories should be small. They should be achievable by a pair within an iteration with lots of time to spare. If your iteration is one week, your maximum story size should be a few days’ work at most. If it’s two weeks, you might accept a story that would take a pair a week to perform.

Testable – In order for developers to know they’re done with a story, it should have a test (or tests) that prove it works. This test should be written by the customer (if only in English, if not using a tool like Fit). Stories should have definite criteria for success. “Improve performance” or “make the UI intuitive” are impossible to nail down with numbers. “Performs 20 request/sec under load with product database loaded and 100 concurrent users” is much easier to write a test for.

Following the INVEST acronym should result in stories which are much easier to use in your agile estimating and planning. During the iteration retrospective, pay particular attention to stories that didn’t get done during the iteration, and identify any deficiencies they have from an INVEST point of view. If you’re consistently seeing the same kinds of problems with your failing stories, you’ve identified a problem with your process that you should address. From a lean software development perspective, you’ll want to perform root cause analysis and correct the problem, rather than working around it.

Determine Whether an Assembly was compiled in Debug Mode

ssmith — Thu, 18 Jun 2009 02:48:47 GMT

I’m working on a little application right now that provides some insight into the assemblies in use for a given application. One of the things that I want to be able to show is whether or not each assembly was built in Debug or Release mode. As you’re no doubt aware, running applications in production that were built in Debug mode can be a major performance problem (at a minimum – depending on what else you have turned on in Debug mode it could also be a security issue).

So I did some binging (followed by some purging? no, wait, that with a hard G sound) and quickly found some sample code that I was able to use in some test code to confirm that it is working. Fellow MVP Bill McCarthy wrote (like, 5 years ago to the day!) about how to do this in Visual Basic. Not that I have anything against VB, but my preference since VB6 has been C# (if nothing else, it makes JavaScript much easier to grok), so I had to translate the code into my native tongue, which provides me with something to share with you. This is literally Bill’s code, translated by me into C#. Any bugs you can probably assign to me as the translator, rather than Bill as original author.

Check If An Assembly Was Compiled In Debug Mode

private bool IsAssemblyDebugBuild(string filepath)

    return IsAssemblyDebugBuild(Assembly.LoadFile(Path.GetFullPath(filepath)));

private bool IsAssemblyDebugBuild(Assembly assembly)

    foreach (var attribute in assembly.GetCustomAttributes(false))

        var debuggableAttribute = attribute as DebuggableAttribute;

        if(debuggableAttribute != null)

            return debuggableAttribute.IsJITTrackingEnabled;

    return false;

(subscribe to my blog)
(follow me on twitter)

The Fibonacci Blog Post Formatter

ssmith — Thu, 11 Jun 2009 19:50:00 GMT

Sarah suggested Tuesday that I write a blog PostFormatter that only changed the format of blog posts created on days that were Fibonacci Sequence days (e.g. 1, 2, 3, 5, 8…). I’d hoped to code something like that up during my Ann Arbor talk last night but ended up not having the time, so just to show how easily this could be done, I threw something together today.

First, this is for a demo application that I used in my talks this week – if you want to follow along, grab the code from my last post.

I already had a well-tested but not at all optimized Fib generator/tester class from some Euler problems I’d worked on as part of a coding kata, so I just reused that for the formatter. The complete code for the new IPostFormatter implementation is shown here:

public class FibPostFormatter : IPostFormatter

    public Post FormatPost(Post post)

        var fibChecker = new FibonacciChecker();

        if (fibChecker.IsFib(post.DatePosted.Day))

            post.Title = "[FibDate!] " + post.Title;

        post.EncodedTitle = Utility.BuildFriendlyUrl(post.Title);

        post.Abstract = Utility.GetAbstract(post.Contents);

        return post;

    private class FibonacciChecker

        private List<int> fibNumbers;

        public FibonacciChecker()

            fibNumbers = new List<int>();

        public bool IsFib(int numberToTest)

            var fibNumbers = new List<int>();

            fibNumbers = GenerateFibs(numberToTest);

            return fibNumbers.Contains(numberToTest);

        public List<int> GenerateFibs(int upperBound)

            fibNumbers = new List<int>();

            if (fibNumbers.Count == 0)

                fibNumbers.Add(1);

                fibNumbers.Add(2);

            int index = 2;

            int term = 0;

            while (term <= upperBound)

                term = fibNumbers[index - 2] + fibNumbers[index - 1];

                fibNumbers.Add(term);

                index++;

            return fibNumbers;

Again, it could benefit from some optimization – it was the result of a timeboxed Euler exercise and it certainly is adequate for testing of days up to and including 31.

Naturally I wanted to be sure this worked, so I added the following test class:

using System;

using System.Collections.Generic;

using Microsoft.VisualStudio.TestTools.UnitTesting;

using SolidBlog.Controllers;

using SolidBlog.Models;

namespace SolidBlog.Tests.Formatters

    [TestClass]

    public class PostFormatterTester

        private const string TEST_TITLE = "test title";

        private FibPostFormatter _fibPostFormatter;

        private const string EXPECTED_PREFIX = "[FibDate!] ";

        [TestInitialize]

        public void Setup()

            _fibPostFormatter = new FibPostFormatter();

        [TestMethod]

        public void FibDaysShouldBeFormattedAsFib()

            var fibDays = new List<int>() {1, 2, 3, 5, 8, 13, 21};

            foreach (var day in fibDays)

                Post myPost = _fibPostFormatter.FormatPost(GetTestPostForDayOfJanuary(day));

                Assert.AreEqual(EXPECTED_PREFIX + TEST_TITLE, myPost.Title,

                    "Didn't format title correctly for fib day " + day);

        [TestMethod]

        public void NonFibDaysShouldNotBeFormattedAsFib()

            var fibDays = new List<int>() { 4, 6, 7, 9, 10, 11, 12, 14, 15, 16, 17, 18, 19,

                20, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31 };

            foreach (var day in fibDays)

                Post myPost = _fibPostFormatter.FormatPost(GetTestPostForDayOfJanuary(day));

                Assert.AreEqual(TEST_TITLE, myPost.Title,

                    "Formatted title incorrectly for nonfib day " + day);

        private Post GetTestPostForDayOfJanuary(int day)

            DateTime testPostDate = new DateTime(2009, 1, day);

            var myPost = new Post() { DatePosted = testPostDate, Title = TEST_TITLE,

                Abstract = "", Contents = "" };

            return myPost;

Both tests pass. Finally, to wire this up in my blog application, I simply need to turn on the IoC stuff in global.asax (uncomment line 35) and be sure to use the new Create() action of my PostController (line 175 in PostController needs renamed to Create and the other Create() renamed to something else). Finally, change the IPostFormatter line in ConfigureIoC() in global.asax (line 51/52) to the following:

StructureMapConfiguration.BuildInstancesOf<IPostFormatter>().TheDefaultIsConcreteType
    <FibPostFormatter>();

With that you can run the app and if you happen to create a new post on one of the Fib sequence days of the month, you’ll see that it makes a note of this by prefixing the title with “[FibDate!] “.

Note that to achieve this (assuming that the application we were changing already was using IoC and the refactored version of Create()) we didn’t have to change any existing code (well, ok, one line of IoC bootstrapping code). That’s the Open/Closed Principle. Adding additional features or changing the system’s behavior should not require that you change existing code, but rather that you encapsulate new behavior into new classes that can be swapped out via the interfaces used to refer to them.

a2chrisn4u

ASP.NET MVC and SOLID Programming Principles June 2009

ssmith — Thu, 11 Jun 2009 18:15:09 GMT

This week I presented “Introducing ASP.NET MVC and SOLID Programming Principles” (aka SOLIDify Your ASP.NET MVC) to the Cleveland .NET SIG and the Ann Arbor .NET Developers group. Thanks to everyone who came, it was standing room only at the Microsoft office in Cleveland and a great turnout at the SRT Solutions office in Ann Arbor, too. I thought the presentation went well and had some good discussion in both locations and I enjoyed getting to see a lot of folks I know in the area whom I hadn’t seen in a while. And the projector didn’t turn off every 5 minutes like the last time I spoke in Ann Arbor (always bonus).

Download

ASP.NET MVC and SOLID Programming Principles Slides and Demos

The only difference between the two talks is that for Ann Arbor I put together a 2-slide example showing how one’s solution would be organized in order to not have all projects ultimately referencing the Data Access Layer (DAL). I mentioned this concept Tuesday in Cleveland but didn’t have a visual to go with it, so I threw something together for Wednesday (and eventually it will make its way into the actual presentation). In fact, here are those two slides for reference:

If you follow ISP and try to keep your interfaces with their consumers (typically in your business/domain model/core project) then your data access project needs to reference this project in order to implement these interfaces.

Binding in ASP.NET MVC

ssmith — Wed, 10 Jun 2009 15:30:22 GMT

At my ASP.NET MVC + SOLID Principles talk in Cleveland last night, I had a couple of questions about binding in ASP.NET MVC. For instance:

Can you still do something like <%= Bind(“Foo”) %> in your form?
How does the controller that receives a POST get back the Model that was used in the form that was posted?
Does it have to be serializable?
What if I need to bind custom types to my Model class?
Doesn’t having the Model referenced in the View eliminate the need for the Controller?

I answered these last night but I thought they were common enough as a theme that they deserved their own answers here as well.

Does ASP.NET MVC Support Two Way Binding via the Bind() Syntax?

No, not directly. Rather, you can use HTML Helpers to create your UI (if you like – you can also just hand code the HTML if that’s your preference – ASP.NET MVC is all about you being in control), and then use either the built-in or a custom ModelBinder to convert the POSTed data into your class/Model. More on ModelBinders below. The HTML helper syntax might look like this:

<%= Html.TextBox("Title", Model.Title) %>

If you don’t like the “magic string” used in this, you might look at Eric Hexter’s Input Builders project.

How does the controller that handles the POST get back the Model?

In my example last night, I had some code that looked like this (except it used a blog not a customer):

[AcceptVerbs(HttpVerbs.Post)]

public ActionResult Create(Customer customer)

   // work with Customer here

This kind of looks like it’s using Magic, because nowhere am I having to deal with Request.Form[“CustomerName”] or CustomerTextBox.CustomerName as I would typically need to do. It raises the question for some as to whether there is some kind of passing around of the serialized model (Customer) between the client and the server. In fact this is not the case. All that is happening here is standard HTTP, doing a POST, with the fields that were specified in the <form> on the client. If our form had an <intput type=”text” name=”CustomerName” /> then the POST would include the CustomerName field and whatever value was stored in the TextBox.

The “magic” takes place in the form of a ModelBinder. ModelBinders are responsible for the fairly common task of converting between a collection of Form values and a strongly typed Model class that should be created from these values. First, let’s look at the equivalent code that doesn’t use a ModelBinder. If I wanted to create my customer object more explicitly in the controller, I could do it like this:

[AcceptVerbs(HttpVerbs.Post)]

public ActionResult Create(FormCollection formValues)

  var customer = new Customer();

  customer.FirstName = Request.Form["FirstName"];

  customer.LastName = Request.Form["LastName"];

This gets old fast. A better method that is one step closer to the ModelBinder approach would be:

[AcceptVerbs(HttpVerbs.Post)]

public ActionResult Create(FormCollection formValues)

  var customer = new Customer();

  UpdateModel(customer);

This helper method automatically updates the properties of the object we pass into it with the values from incoming form parameters (using reflection to match up the property names with the form names). If we want to avoid dealing directly with the FormCollection in our controller, we can simply use the original signature I showed above, and have the controller take in as its parameter the model object (Customer in this case) that we want to have populated from the form.

If there are problems with the population of the model object, the ModelState.IsValid property will be false, and the ModelState will include details about the rule violations (such as a type mismatch). You can find more detail on this here.

Does the Model used for a controller that handles a POST need to be serializable?

No, it simply needs to have properties that can be mapped to the fields coming in from the POST. The class itself is never serialized or deserialized or sent over the wire. It’s simply mapped from the POSTed fields by a ModelBinder.

What if I need to bind custom types to my Model class?

In this case, you’ll want to write your own ModelBinder and register it so that ASP.NET MVC knows to use it when faced with a given type in your application. Writing a ModelBinder simply requires that you inherit from DefaultModelBinder and override the ConvertType() method. In order to register your type with its custom ModelBinder, you would do this:

// In Global.asax Application Start or an HttpModule

ModelBinders.Binders.Add(typeof(Customer), new CustomerBinder());

Here is a good example of writing a custom ModelBinder class.

Doesn’t having the Model referenced in the View eliminate the need for the Controller?

In response to seeing code in the View like this:

<%= ViewData.Model.FirstName %>

Someone asked if this was stepping on the responsibilities of the Controller, since the View was talking directly to the Model. Here there can be differing opinions. It’s not strictly required that you pass your Model classes to the View. You can simply pass in collections of strings via ViewData. Another common approach is to use a DTO (Data Transfer Object) or ViewModel (the “VM” in the MVVM palindrome pattern) which typically is a subset of one or more Model classes in your application that contains only the information necessary for a given View. It’s also not uncommon to pass your Model into the View. It’s a matter of preference and there are pros and cons to these approaches.

What is not recommended is for your Model (the Customer in my example here, which has a FirstName property) to be persistence aware and to magically go and fetch itself from the database when it is referenced by the View. The above code should only work if the Controller has explicitly passed in the Model to the View, using code like this:

public void View(int id)

  Customer customer = customerRepository.GetCustomer(id);

  return View(customer);

It is still the responsibility of the Controller to pass in whatever data the view needs. The view should not have this responsibility. Nor should the model know how to persist itself. This separation of concerns ensures loose coupling, testability, and a more flexible design.

An example of using a ViewModel/DTO would be something like this:

public class CustomerSummaryViewModel

  public string FirstName { get; set; }

  public string LastName { get; set; }

  public DateTime DateOfLastPurchase { get; set; }

  publi DateTiem AmountOfLastPurchase { get; set; }

...

public void Summary(int id)

  Customer customer = customerRepository.GetCustomer(id);

  Order order = orderRepository.List(id).Take(1); // gets most recent order

  var summary = new CustomerSummaryViewModel() {

    FirstName = customer.FirstName,

    LastName = customer.LastName,

    DateOfLastPurchase = order.DatePurchased,

    AmountOfLastPurchase = order.Amount };

  return View(summary);

Using this approach, the View will have access only to the exact pieces of data that it requires, and no more. If you want to ensure that the View never calls methods on your Model objects or you want to verify with tests that your View is receiving exactly the data that it needs, then using this ViewModel/DTO approach can be valuable.

DRY - Don’t Repeat Yourself - Motivator

ssmith — Mon, 08 Jun 2009 17:16:00 GMT

I’ve been meaning to create a DRY (Don’t Repeat Yourself) motivational poster for a while now, ever since seeing Derick Bailey’s SOLID posters. To me, DRY is at the heart of many software patterns and principles, and sums up much better the similar Once and Only Once principle (which, to me, violates DRY right in its own name).

Duplication is waste.

Repetition in process calls for automation; repetition in logic calls for abstraction.

Refactor to remove wasteful repetition as often as you possibly can, and watch your software design improve. Post this on the wall in your team room (along with others) to keep this principle in mind as you’re writing code.

Create similar motivational posters using Motivator.

Creative Commons License

Since I bugged Derick about having a license on his images, it’s only fair that I include one here as well. It’s simply a Creative Commons license.