Declarative Programming

ASP.NET Routing: Regex Constraints are inneficient

2013-05-18T22:59:00.000-04:00

There are cases where using Regex constraints makes sense and does the job. For example, for action and controller parameters. If you have a constraint like action = "Index|About|Contact", that will prevent the handling, and URL generation, of non-existing actions. The framework only needs a string, from a list of valid values.

But, if the route parameter will eventually map to a type different than string, like an enum or a numeric type, then you are effectively parsing twice. For example, let's say we have a route parameter foo, with a constraint \d+, that maps to an action parameter foo of type Int32:

If the route matches the constraints are processed (Regex parsing).
If the constraint passes the string value of foo is added to RouteData.
Before action invocation, the string value of foo is converted to Int32 using System.Convert, which calls Int32.Parse (Type parsing).

Apart from the unnecessary double parsing, Regex parsing might not be 100% accurate and could match values that the Type parsing will later reject.

The process makes even less sense on URL generation:

You pass an Int32 value for the foo parameter.
Routing converts it to a string, to execute Regex parsing.
If Regex matches the URL is generated.

There's no need for Regex or any kind of parsing when I already have a value of the correct type. The problem is that the route doesn't know which type a route parameter maps to. To solve this, I came up with an IRouteConstraint that works like this:

public bool Match(HttpContextBase httpContext, Route route, string parameterName, RouteValueDictionary values, RouteDirection routeDirection) {

   object originalVal = values[parameterName];

   if (originalVal == null)
      return true;

   if (this.type.IsInstanceOfType(originalVal))
      return true;

   string stringVal = Convert.ToString(originalVal, InvariantFormatProvider);

   if (stringVal.Length == 0)
      return true;

   object parsedVal;

   if (!TryParse(stringVal, InvariantFormatProvider, out parsedVal))
      return false;

   if (routeDirection == RouteDirection.IncomingRequest)
      values[parameterName] = parsedVal;

   return true;
}

What the above code does is:

If the value is null or converts to an empty string then return true, which basically says ignore this constraint. If a route parameter is not optional then routing takes care of it by rejecting null or empty values.
If the value is an instance of the type then return true, no need for further processing. This is usually true on URL generation and when using default values.
If Type parsing is successful then return true, otherwise false. Also, for incoming requests, replace the string value with the parsed value. Because the values parameter is an original dictionary and not a copy, this means that when RouteDataValueProvider is asked for a foo parameter of type Int32 it will already have a value of that type and won't need to call Int32.Parse again.

Check out this gist for the complete code.

Delegate-based strongly-typed URL generation in ASP.NET MVC

2013-04-18T20:04:00.000-03:00

The standard way of generating URLs in ASP.NET MVC involves hard-coding action, controller and parameter names:

string url = Url.Action("Edit", new { id = 5 });

You are probably familiar with the expression tree-based strongly-typed URL generation approach, which is part of the MvcFutures library. It allows you to write code like this:

string url = Url.Action(() => Edit(5));

Actually, MvcFutures does not extend UrlHelper, but it exposes the low-level implementation methods so you can easily write the extension method yourself. If you wanted to link to an action in a different controller you could do it like this:

string url = Url.Action<ProductController>(c => c.Edit(5));

The downside of this expression tree-based approach is that it's slow, two or three times slower than the standard approach.

Delegate-based approach

Instead of expression trees, why not just use delegates?

string url = Url.Action(Edit, 5);

The above code looks even better than the expression tree-based example, and is as fast as the standard approach. The only downside of using delegates is that you need a non-null instance of the controller, which is not a problem when linking to other actions in the same controller, but to link to a different controller you would have to create an instance:

var controller = new ProductController();
string url = Url.Action(controller.Edit, 5);

The instantiation of a controller could involve the execution of unneeded initialization code, for the purposes of just creating a URL. This is where we go back to needing expression trees. Perhaps we could use GetUninitializedObject, although I'm not sure how fast it is, and it doesn't work in medium trust.

Still, when linking to other actions in the same controller this is my new favorite approach. And it works in views also, like this:

var controller = (MyController)ViewContext.Controller;
string url = Url.Action(controller.Edit, 5);

Implementation

The code is quite simple, don't let the overloads scare you. Generic type inference is key:

static class StronglyTypedLinkExtensions {

   static readonly ConcurrentDictionary<MethodInfo, string> actionNames = new ConcurrentDictionary<MethodInfo, string>();

   public static string Action(this UrlHelper urlHelper, Func<ActionResult> action) {
      return ActionImpl(urlHelper, action, default(object[]));
   }

   public static string Action<T>(this UrlHelper urlHelper, Func<T, ActionResult> action, T arg) {
      return ActionImpl(urlHelper, action, arg);
   }

   public static string Action<T1, T2>(this UrlHelper urlHelper, Func<T1, T2, ActionResult> action, T1 arg1, T2 arg2) {
      return ActionImpl(urlHelper, action, arg1, arg2);
   }

   public static string Action<T1, T2, T3>(this UrlHelper urlHelper, Func<T1, T2, T3, ActionResult> action, T1 arg1, T2 arg2, T3 arg3) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3);
   }

   public static string Action<T1, T2, T3, T4>(this UrlHelper urlHelper, Func<T1, T2, T3, T4, ActionResult> action, T1 arg1, T2 arg2, T3 arg3, T4 arg4) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3, arg4);
   }

   public static string Action<T1, T2, T3, T4, T5>(this UrlHelper urlHelper, Func<T1, T2, T3, T4, T5, ActionResult> action, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3, arg4, arg5);
   }

   public static string Action<T1, T2, T3, T4, T5, T6>(this UrlHelper urlHelper, Func<T1, T2, T3, T4, T5, T6, ActionResult> action, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3, arg4, arg5, arg6);
   }

   public static string Action<T1, T2, T3, T4, T5, T6, T7>(this UrlHelper urlHelper, Func<T1, T2, T3, T4, T5, T6, T7, ActionResult> action, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3, arg4, arg5, arg6, arg7);
   }

   public static string Action<T1, T2, T3, T4, T5, T6, T7, T8>(this UrlHelper urlHelper, Func<T1, T2, T3, T4, T5, T6, T7, T8, ActionResult> action, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7, T8 arg8) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8);
   }

   public static string Action<T1, T2, T3, T4, T5, T6, T7, T8, T9>(this UrlHelper urlHelper, Func<T1, T2, T3, T4, T5, T6, T7, T8, T9, ActionResult> action, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7, T8 arg8, T9 arg9) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9);
   }

   public static string Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10>(this UrlHelper urlHelper, Func<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, ActionResult> action, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7, T8 arg8, T9 arg9, T10 arg10) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10);
   }

   public static string Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11>(this UrlHelper urlHelper, Func<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, ActionResult> action, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7, T8 arg8, T9 arg9, T10 arg10, T11 arg11) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10, arg11);
   }

   public static string Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12>(this UrlHelper urlHelper, Func<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, ActionResult> action, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7, T8 arg8, T9 arg9, T10 arg10, T11 arg11, T12 arg12) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10, arg11, arg12);
   }

   public static string Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13>(this UrlHelper urlHelper, Func<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, ActionResult> action, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7, T8 arg8, T9 arg9, T10 arg10, T11 arg11, T12 arg12, T13 arg13) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10, arg11, arg12, arg13);
   }

   public static string Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14>(this UrlHelper urlHelper, Func<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, ActionResult> action, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7, T8 arg8, T9 arg9, T10 arg10, T11 arg11, T12 arg12, T13 arg13, T14 arg14) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10, arg11, arg12, arg13, arg14);
   }

   public static string Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15>(this UrlHelper urlHelper, Func<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, ActionResult> action, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7, T8 arg8, T9 arg9, T10 arg10, T11 arg11, T12 arg12, T13 arg13, T14 arg14, T15 arg15) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10, arg11, arg12, arg13, arg14, arg15);
   }

   public static string Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>(this UrlHelper urlHelper, Func<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16, ActionResult> action, T1 arg1, T2 arg2, T3 arg3, T4 arg4, T5 arg5, T6 arg6, T7 arg7, T8 arg8, T9 arg9, T10 arg10, T11 arg11, T12 arg12, T13 arg13, T14 arg14, T15 arg15, T16 arg16) {
      return ActionImpl(urlHelper, action, arg1, arg2, arg3, arg4, arg5, arg6, arg7, arg8, arg9, arg10, arg11, arg12, arg13, arg14, arg15, arg16);
   }

   static string ActionImpl(this UrlHelper urlHelper, Delegate action, params object[] args) {

      RouteValueDictionary values = null;

      if (args != null
         && args.Length > 0) {

         values = new RouteValueDictionary();

         var parameters = action.Method.GetParameters();

         for (int i = 0; i < parameters.Length; i++)
            values[parameters[i].Name] = args[i]; 
      }

      string actionName = actionNames.GetOrAdd(action.Method, m => {
            
         ActionNameAttribute attr = m
            .GetCustomAttributes(typeof(ActionNameAttribute), inherit: true)
            .Cast<ActionNameAttribute>()
            .SingleOrDefault();

         return (attr != null) ?
            attr.Name
            : m.Name;
      });

      return urlHelper.Action(actionName, values);
   }
}

Attribute-based routing coming to ASP.NET MVC and Web API v5

2013-03-29T01:36:00.001-03:00

Attribute-based routing is coming to ASP.NET MVC and Web API, according to the roadmap. They are basing the solution on the popular AttributeRouting project. At the date of writing this post only Web API support is working, you can play with it by installing the nightly packages.

For a number of reasons I do not like the original project the ASP.NET team is basing on.

Not very DRY

There are many things that could be infered by the code, yet you have to be explicit about it. For instance:

[HttpGet("hello/{a:int}")]
public string Hello(int a) {
   return "Hi! " + a;
}

Why do I need to declare int in the route, if I could just take that information from the method parameter?

No grouping

Instead of grouping routes that are similar, all declared attribute routes map to a registered route. I don't like the idea of having 650 routes like stackoverflow. It does not sound efficient. Can you imagine just looking at all those routes? What about matching the 650th route for URL generation? I bet stackoverflow hardcode URLs.

No context

Attribute routes are absolute, they do not take into account any information about where the action is located in the code, such as the controller, namespace, etc. This means the code that uses attribute routing is not portable.

Conventional vs. Custom Routes

The default route {controller}/{action}/{id} was not a bad start. You could develop a whole application without worrying about routing. Of course, at some point, the need for more customized routes arises. But that doesn't mean you should throw away conventions and use only custom routes. You just need a more flexible convention, and have the ability to do custom routes when needed. That's what MvcCodeRouting provides.

The good thing is that, just like Areas, you can just ignore attribute routing.

Rethinking ASP.NET MVC: Workflow per Controller

2013-02-08T19:50:00.000-03:00

My most controversial answer on StackOverflow is to a question about how to organize an ASP.NET MVC application. My answer was:

Separating classes by category (Controllers, ViewModels, Filters etc.) is nonsense.

If you want to write code for the Home section of your website (/) then create a folder named Home, and put there the HomeController, IndexViewModel, AboutViewModel, etc. and all related classes used by Home actions.

If you have shared classes, like an ApplicationController, you can put it at the root of your project.

Why separate things that are related (HomeController, IndexViewModel) and keep things together that have no relation at all (HomeController, AccountController) ?

This was downvoted for a long time. Eventually people started upvoting and now it's on the positive. People started to realize what a pain it is to maintain an app where the code for a single function is scattered all over the place. Categorization of information is useful if there's value in looking at all information of a certain category at once. For example, in Reflector you can look at all derived types of a certain type, which is super useful. Such function would be a great addition to Visual Studio. Back to MVC, if I could ask Visual Studio to show me all controllers, without having to put all controllers in the same directory/namespace, that would be great too. Because, when it comes to organizing code, keeping related types together is the best option for maintainability, specially of large codebases.

Controllers and Namespaces

So, for a long time I've been putting controllers and related view models in their own namespace. MvcCodeRouting makes it easy. But this lead to a new problem. Since, to take advantage of model validation and model metadata you have to write classes, it's natural in MVC to end up with a lot of classes. This lead to having namespaces with too many classes, many of these were unrelated view models. The problem started by having too many actions per controller. How many actions should a controller have? Some are going as far as having one action per controller. I wouldn't go that far. I think a controller should implement a single workflow, and that workflow should have its own namespace.

Workflow per Controller

So, what is a workflow? Let's take MvcAccount for example. There's a Reset Password function comprised of several actions:

GET /Account/ResetPassword
POST /Account/ResetPassword
GET /Account/PasswordResetVerificationSent
GET /Account/RP (by clicking on e-mail link)
POST /Account/RP
GET /Account/PasswordReset

To successfully reset a password you have go through this sequence of actions from start to finish. This is the Reset Password workflow, and should be represented in code by its own controller. This means going from:

namespace MvcAccount {
   
   public class AccountController : Controller {

      public ActionResult ResetPassword() { ... }

      [HttpPost]
      public ActionResult ResetPassword(ResetPasswordInput input) { ... }

      public ActionResult PasswordResetVerificationSent() { ... }

      public ActionResult RP(string id) { ... }

      [HttpPost]
      public ActionResult RP(string id, FinishResetPasswordInput input) { ... }

      public ActionResult PasswordReset() { ... }

      // ... lots of other unrelated actions below
   }
}

To:

namespace MvcAccount.Password.Reset {

   public class ResetController : Controller {

      public ActionResult Reset() { ... }

      [HttpPost]
      public ActionResult Reset(ResetInput input) { ... }

      public ActionResult VerificationSent() { ... }

      public ActionResult Finish(string id) { ... }

      [HttpPost]
      public ActionResult Finish(string id, FinishInput input) {... }

      public ActionResult Done() { ... }
   }
}

Pros

Codebase neatly organized: No more namespaces with too many classes. All of the Reset Password workflow classes, which includes the controller and view models, sit in the MvcAccount.Password.Reset namespace. The parent namespace, MvcAccount.Password, can also be used to group related workflows, e.g. MvcAccount.Password.Change. These can be considered related workflows because: a) they act on the same resource, or b) they share some infrastructure code (e.g. data access).

Smaller controllers: yep.

Shorter names of actions and view models: Namespaces gives us qualification and frees us from naming conflicts. PasswordResetVerificationSent becomes VerificationSent, and FinishResetPasswordInput becomes FinishInput. This also means shorter names for views.

Simpler dependency injection: Controller can take dependencies required by the workflow only.

If implementation is simple enough you can move it to the controller class or workflow namespace: I won't get into a religious war about where the service or domain layer should go, whether it should be separate from the web layer, etc. etc., but since the controller is a lot smaller, and the workflow namespace only has a few classes, then there's a lot more you can put there.

Cons

Can produce longer routes: In some cases, it won't change much. For example, using MvcCodeRouting /Account/PasswordResetVerificationSent becomes /Account/Password/Reset/VerificationSent. But /Account/ResetPassword becomes /Account/Password/Reset/Reset. Why Reset twice? First Reset for the controller, second for the action. This can be avoided by changing the action to Index, but I don't think that's a good name considering what the action does. Perhaps having a second convention for default actions, one where the action name is the same as the controller name, would help. In any case, when conventional routes are too long you can always resort to custom routes. Update: MvcCodeRouting v1.1 supports custom default actions.

How to avoid going back

Don't let your routing solution dictate how to organize your code. This was the mistake I made over and over. First I thought about the URL I wanted to implement, then I thought where in the project I had to put the code to implement that URL. This is how you end up with messy codebases. Always think first about the proper way to organize your code, then worry about routing and URLs.

Show me the code

Before: https://mvcaccount.codeplex.com/SourceControl/BrowseLatest

After: https://github.com/maxtoroq/MvcAccount

My life is an anti-pattern

2013-01-12T13:50:00.000-03:00

For some reason people often look for THE solution to a particular problem, ignoring the fact that the best solution to any problem depends on its inputs. In other words, if someone asks you something there are two answers that are always correct: I don't know and it depends. These phrases probably won't help you much if you are a business man of a politician, but as programmers we should feel comfortable saying, specially the latter. Because, that IS what we do, right? Take some input, program some logic and return a result.

Yet, there are ideas some programmers put forward as THE right solution, ALWAYS. Meaning, if you're not doing it that way your code is inferior. Things like best practices, design principles, design patterns, and the worst of all, rules of thumb. The most important argument in favor of these ideas is that they are proven to work. Well, except for rules of thumb, which are just designed to work most of the time.

Proven

So, if something is proven it should be useful, right? It depends on your particular problem. Just because ORM, Repository, Unit of Work, LINQ to X are proven it doesn't mean they are good choices for a high traffic website, for example. So, it's the degree of utility, what you gain vs. what you lose. Proven means it works, it doesn't mean it's exactly what you need.

Anti-patterns

Not following a pattern, like fat models, thin controllers, session per request, means I'm following an anti-pattern? Of course not. It doesn't mean you are against (anti) that particular pattern, or that what you are doing instead is therefore wrong. This dualism is very common in our society: if you are not a capitalist you must be a communist, if you are not a republican you must be a democrat, and so on. It's a way for people to defend their beliefs by avoiding any reasoning. I'm not against patterns, all I'm saying is IT DEPENDS. Pattern advocates should not feel the need to defend their beliefs by calling the opposite or absence of their pattern an anti-pattern.

Endless What ifs

What if some day you want to change ORM, or database server, or logging library? Don't use that static helper, what if you need to test that method? What if? What if?...

Well, when that day comes I'll worry about that. If it isn't a requirement today, YAGNI. Software development, specially application development, shouldn't be so focused on design decisions or making the code as politically correct as it can be. In fact, following too many patterns, specially abstraction patterns, can make your code perform worse, harder to understand, harder to maintain, etc. Design patterns are a form of complexity.

All problems are unique

My advice to you, dear reader, is don't think about a type of problem, focus on what makes your problem unique, and you'll end up with the best solution.

MvcPages: ASP.NET MVC without routes and controllers

2012-11-01T02:11:00.003-03:00

I like developing with ASP.NET MVC, but sometimes I feel there are too many pieces involved. To develop a single function you have to (in no particular order):

Create route (make sure it doesn't break other routes)
Create controller/action
Create view model
Create view

... in addition to writing the model/service that does the actual work. Even though this layering gives you a lot of flexibility and testability, sometimes you don't need it. Do you really need all of the above to develop a simple contact form? Do you ever test your controllers/views? Do you have a lot of actions that just return View()?

ASP.NET Web Pages

Web Pages has the simplicity I sometimes want, except you lose a lot of power. With Web Pages everything is parameter-based, there's no need to ever write a single class. MVC also has support for parameter-based approach (action method parameter binding, ViewData/ViewBag), but the really nice features such as attribute-based validation and forms generation (EditorForModel) work with classes. These are the features I'm not willing to give up.

MvcPages

Forget about routes, forget about controllers, keep everything else. That's MvcPages, a very small library with no original features, just a base page class that allows you to access MVC features directly from standalone Razor pages. For example, this is a standard Web Pages page:

@{
   if (!User.Identity.IsAuthenticated) {
      FormsAuthentication.RedirectToLoginPage();
      return;
   }

   Validation.RequireField("currentPassword", "The current password field is required.");
   Validation.RequireField("newPassword", "The new password field is required.");
   
   Validation.Add("newPassword",
      Validator.StringLength(
         maxLength: 100,
         minLength: 6,
         errorMessage: "New password must be at least 6 characters"));
         
   Validation.Add("confirmPassword",
      Validator.Required("The confirm new password field is required."),
      Validator.EqualsTo("newPassword", "The new password and confirmation password do not match."));

   if (IsPost
      && Validation.IsValid()) {

      string currentPassword = Request.Form["currentPassword"];
      string newPassword = Request.Form["newPassword"];
      string confirmPassword = Request.Form["confirmPassword"];

      bool passwordChanged = true; /* code that changes password here */

      if (passwordChanged) {
         Response.Redirect("ChangePasswordSuccess");
         return;
      } else {
         ModelState.AddFormError("An error occurred when attempting to change the password. Please contact the site owner.");
      }
   }

   Page.Title = "Change Password";

   <h1>@Page.Title</h1>
   @Html.ValidationSummary("Password change was unsuccessful. Please correct the errors and try again.", true)
   
   <form method="post">
      <div class="editor-label">
         <label for="currentPassword">Current password</label>
      </div>
      <div class="editor-field">
         <input type="password" id="currentPassword" name="currentPassword" @Validation.For("currentPassword")/>
      </div>

      <div class="editor-label">
         <label for="newPassword">New password</label>
      </div>
      <div class="editor-field">
         <input type="password" id="newPassword" name="newPassword" @Validation.For("newPassword")/>
      </div>

      <div class="editor-label">
         <label for="confirmPassword">Confirm new password</label>
      </div>
      <div class="editor-field">
         <input type="password" id="confirmPassword" name="confirmPassword" @Validation.For("confirmPassword")/>
      </div>

      <br />
      <button>Change Password</button>
   </form>
}

Ugly, long, terrible. This is the same page using MvcPages:

@using Samples.Account
@model ChangePasswordModel
@{
   var service = new AccountService(ModelState);
   
   if (!User.Identity.IsAuthenticated) {
      FormsAuthentication.RedirectToLoginPage();
      return;
   }

   if (IsPost
      && TryUpdateModel()
      && service.ChangePassword(Model)) {
      
      Response.Redirect("ChangePasswordSuccess");
      return;
   }

   ViewBag.Title = "Change Password";

   <h1>@ViewBag.Title</h1>
   @Html.ValidationSummary(true, "Password change was unsuccessful. Please correct the errors and try again.")
   
   using (Html.BeginForm()) {
      @Html.EditorForModel()
      <br />
      <button>Change Password</button>
   }
}

Same ol' MVC. You know the features: model binding, model validation, strongly-typed HTML helpers, editor and display templates, TempData, etc.

Also, a new feature: Layout compatibility. Ever tried using an MVC layout from Web Pages? you get:

Server Error in '/' Application.

The view at '~/SomePage.cshtml' must derive from WebViewPage, or WebViewPage<TModel>.

With MvcPages it's possible. You can now add Web Pages to your MVC app and use the same layout as your views.

Like it? NuGet it, or fork it, or whatever.

Implementing a contact form plugin for ASP.NET MVC

2012-10-27T00:33:00.000-03:00

The purpose of this post is to demonstrate the patterns presented in the Patterns for ASP.NET MVC Plugins series so far.

Routes, Controllers and Configuration
View Models
Demo: Implementing a contact form plugin

I've chosen the contact form scenario because it's a very common requirement most developers are familiar with. Also, the implementation is short and straightforward. The idea is that you focus on the patterns rather than the actual functionality of the plugin. The same patterns can be used to implement more interesting plugins.

Model

The model for the plugin is a very simple one, only four fields that the user needs to enter.

public class ContactInput {

   [Required]
   [StringLength(100)]
   [Display(Order = 1)]
   public virtual string Name { get; set; }

   [Required]
   [DataType(DataType.EmailAddress)]
   [StringLength(254)]
   [RegularExpression(@"\w+([-+.']\w+)*@\w+([-.]\w+)*\.\w+([-.]\w+)*")]
   [Display(Order = 2)]
   public virtual string Email { get; set; }

   [Required]
   [StringLength(254)]
   [Display(Order = 3)]
   public virtual string Subject { get; set; }

   [Required]
   [StringLength(2000)]
   [DataType(DataType.MultilineText)]
   [Display(Order = 4)]
   public virtual string Message { get; set; }
}

This is what the series call an Input Model, which defines the data that an action takes as input.

Patterns used:

Set Display(Order) for all properties
Name input models after the action method name plus the "Input" suffix
I'm deviating from the pattern here since the action method that uses this input model is Index and not Contact. I'm only using Index to make the URL as short and friendly as possible, and of course for compatibility with the default route. I think ContactInput is a much better name, since Index doesn't mean anything in this case.
Use the virtual modifier on all input model properties
Use the DataTypeAttribute when appropiate

Configuration

The following is the class used to provide configuration settings for the plugin.

public class ContactConfiguration {

   public string From { get; set; }
   public string To { get; set; }
   public string CC { get; set; }
   public string Bcc { get; set; }
   public Func<ContactSender> ContactSenderResolver { get; set; }
}

ContactSender is the class that does the work. ContactSenderResolver is an optional setting used to provide a customized instance of ContactSender, we'll be using it later.

Patterns used:

Service

The following is the definition of ContactSender (some code ommited for clarity).

public class ContactSender {

   readonly SmtpClient smtpClient;
   ContactConfiguration config;
      
   public ContactConfiguration Configuration {
      get { return config; }
      set { config = value; }
   }

   public ContactSender() 
      : this(new SmtpClient()) { }

   public ContactSender(SmtpClient smtpClient) {

      if (smtpClient == null) throw new ArgumentNullException("smtpClient");

      this.smtpClient = smtpClient;
   }

   public virtual ContactInput CreateContactInput() {
      return new ContactInput();
   }

   protected virtual void InitializeContactInput(ContactInput input) { }

   public ContactInput Send() {

      ContactInput input = CreateContactInput();
      InitializeContactInput(input);

      return input;
   }

   public virtual bool Send(ContactInput input) {

      var message = new MailMessage {
         To = { this.config.To },
         ReplyToList = { new MailAddress(input.Email, input.Name) },
         Subject = input.Subject,
         Body = renderViewAsString("_MailHtml", input)
      };

      if (this.config.From != null)
         message.From = new MailAddress(this.config.From);

      if (this.config.CC != null)
         message.CC.Add(this.config.CC);

      if (this.config.Bcc != null)
         message.Bcc.Add(this.config.Bcc);

      try {
         this.smtpClient.Send(message);

      } catch (SmtpException ex) {
            
         LogException(ex);

         return false;
      }

      return true;
   }
}

Patterns used:

View Model

public class IndexViewModel {

   public ContactInput InputModel { get; private set; }

   public IndexViewModel(ContactInput inputModel) {
      this.InputModel = inputModel;
   }
}

Patterns used:

View

@model IndexViewModel

@using (Html.BeginForm()) { 
   @Html.AntiForgeryToken()
   var inputHtml = HtmlUtil.HtmlHelperFor(Html, Model.InputModel);
   @inputHtml.EditorForModel()

   <input type="submit" />
}

Patterns used:

Create an HtmlHelper<TModel> instance for form rendering, where TModel is the input model type

Controller

[OutputCache(Location = OutputCacheLocation.None)]
public class ContactController : Controller {

   ContactConfiguration config;
   ContactSender service;

   public ContactController() { }

   public ContactController(ContactSender service) {
      this.service = service;
   }

   protected override void Initialize(RequestContext requestContext) {
         
      base.Initialize(requestContext);

      this.config = requestContext.RouteData.DataTokens["Configuration"] as ContactConfiguration
         ?? new ContactConfiguration();

      if (this.config.ContactSenderResolver != null)
         this.service = this.config.ContactSenderResolver();

      if (this.service == null)
         this.service = new ContactSender();

      this.service.Configuration = this.config;
   }

   [HttpGet]
   public ActionResult Index() {

      this.ViewData.Model = new IndexViewModel(this.service.Send());
         
      return View();
   }

   [HttpPost]
   public ActionResult Index(string foo) {

      ContactInput input = this.service.CreateContactInput();

      this.ViewData.Model = new IndexViewModel(input);
         
      if (!ModelBinderUtil.TryUpdateModel(input, this)) {
            
         this.Response.StatusCode = (int)HttpStatusCode.BadRequest;
         return View();
      }

      if (!this.service.Send(input)) {
            
         this.Response.StatusCode = (int)HttpStatusCode.InternalServerError;
         return View();
      }

      return RedirectToAction("Success");
   }

   [HttpGet]
   public ActionResult Success() {
      return View();
   }
}

Patterns used:

Using the plugin

This is how you can register the plugin using MvcCodeRouting.

public static void RegisterRoutes(RouteCollection routes) {
         
   routes.MapCodeRoutes(
      baseRoute: "Contact",
      rootController: typeof(ContactController),
      settings: new CodeRoutingSettings {
         EnableEmbeddedViews = true,
         Configuration = new ContactConfiguration {
            To = "contact@example.com"
         }
      }
   );
}

If you visit /Contact you'll see the contact form.

Adding a field to the form

Let's add a second plugin instance, this time with an extra field. First, we need to inherit ContactInput and add the new property.

public class CustomContactInput : ContactInput {

   [Required]
   [Display(Name = "How did you hear about us?", Order = 3)]
   [UIHint("Source")]
   public virtual string Source { get; set; }
}

Next, inherit ContactSender and override CreateContactInput.

public class CustomContactSender : ContactSender {

   public override ContactInput CreateContactInput() {
      return new CustomContactInput();
   }
}

Note the use of UIHint("Source") on the new property, let's add that editor template.

@Html.DropDownList("", new[] { "Friend", "Advertisement", "Google", "Other" }
   .Select(s => new SelectListItem { Text = s, Value = s }), "")

Lastly, we register this new plugin instance.

routes.MapCodeRoutes(
   baseRoute: "CustomContact",
   rootController: typeof(ContactController),
   settings: new CodeRoutingSettings {
      EnableEmbeddedViews = true,
      Configuration = new ContactConfiguration {
         To = "info@example.com",
         ContactSenderResolver = () => new Models.CustomContactSender()
      }
   }
);

Note I'm also using a different destination address (To configuration setting). If you visit /CustomContact you can see the form with the new field.

Conclusions

Hopefully seeing the patterns in action makes their utility more clear. The goal is to provide a consistent experience for plugin consumers (application developers), minimize the amount of configuration required to get a plugin working in the host application and maximize the plugin's flexibility to customize it's behavior.

Source code

5 reasons why you should use MvcCodeRouting

2012-09-23T19:44:00.000-03:00

MvcCodeRouting v1.0 is out, this post highlights the library's most important features and why I believe is a must have for all ASP.NET MVC developers.

1. Convention over configuration

Getting started with MvcCodeRouting in a new project, or integrating with an existing codebase, requires very little configuration, and many times no configuration at all. This is because the library recognizes that most of the time you follow the {controller}/{action} or {controller}/{action}/{id} convention. For example, let's take the MvcMusicStore application and use MvcCodeRouting on it:

public static void RegisterRoutes(RouteCollection routes)
{
   routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

   //routes.MapRoute(
   //    "Default", // Route name
   //    "{controller}/{action}/{id}", // URL with parameters
   //    new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
   //);

   routes.MapCodeRoutes(
      rootController: typeof(Controllers.HomeController),
      settings: new CodeRoutingSettings {
         UseImplicitIdToken = true
      }
   );
}

Calling MapCodeRoutes is the only change required. You can build and run the application as if nothing changed. If you visit ~/routes.axd you can see the routes that MvcCodeRouting created:

routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

routes.MapRoute(null, "{action}", 
    new { controller = @"Home", action = @"Index" }, 
    new { action = @"Index" }, 
    new[] { "MvcMusicStore.Controllers" });

routes.MapRoute(null, "StoreManager/{action}/{id}", 
    new { controller = @"StoreManager" }, 
    new { action = @"Delete|Details|Edit", id = @"0|-?[1-9]\d*" }, 
    new[] { "MvcMusicStore.Controllers" });

routes.MapRoute(null, "Store/Details/{id}", 
    new { controller = @"Store", action = @"Details" }, 
    new { id = @"0|-?[1-9]\d*" }, 
    new[] { "MvcMusicStore.Controllers" });

routes.MapRoute(null, "Checkout/Complete/{id}", 
    new { controller = @"Checkout", action = @"Complete" }, 
    new { id = @"0|-?[1-9]\d*" }, 
    new[] { "MvcMusicStore.Controllers" });

routes.MapRoute(null, "ShoppingCart/{action}/{id}", 
    new { controller = @"ShoppingCart" }, 
    new { action = @"AddToCart|RemoveFromCart", id = @"0|-?[1-9]\d*" }, 
    new[] { "MvcMusicStore.Controllers" });

routes.MapRoute(null, "Account/{action}", 
    new { controller = @"Account" }, 
    new { action = @"LogOn|LogOff|Register|ChangePassword|ChangePasswordSuccess" }, 
    new[] { "MvcMusicStore.Controllers" });

routes.MapRoute(null, "StoreManager/{action}", 
    new { controller = @"StoreManager", action = @"Index" }, 
    new { action = @"Index|Create|Edit" }, 
    new[] { "MvcMusicStore.Controllers" });

routes.MapRoute(null, "Store/{action}", 
    new { controller = @"Store", action = @"Index" }, 
    new { action = @"Index|Browse|GenreMenu" }, 
    new[] { "MvcMusicStore.Controllers" });

routes.MapRoute(null, "Checkout/AddressAndPayment", 
    new { controller = @"Checkout", action = @"AddressAndPayment" }, 
    new[] { "MvcMusicStore.Controllers" });

routes.MapRoute(null, "ShoppingCart/{action}", 
    new { controller = @"ShoppingCart", action = @"Index" }, 
    new { action = @"Index|CartSummary" }, 
    new[] { "MvcMusicStore.Controllers" });

OK, so the application worked fine with 1 route and now we have 10, how is that better? Well, in some aspects these routes work better (more on that follows), but the point I was trying to make here is how easy it is to start using MvcCodeRouting.

MvcMusicStore is actually not a very good case study, because it only uses the default route ({controller}/{action}/{id}). Routing presents no challenges when you only have one route, but real-world applications use more than one route, and that's when you start facing issues, since adding new routes can potentially break the existing ones.

2. Automatic route grouping, ordering and constraining

Instead of creating one route per action MvcCodeRouting groups similar actions to minimize the number of routes created. For instance, the routes for the StoreManager controller are:

routes.MapRoute(null, "StoreManager/{action}/{id}", 
    new { controller = @"StoreManager" }, 
    new { action = @"Delete|Details|Edit", id = @"0|-?[1-9]\d*" }, 
    new[] { "MvcMusicStore.Controllers" });

routes.MapRoute(null, "StoreManager/{action}", 
    new { controller = @"StoreManager", action = @"Index" }, 
    new { action = @"Index|Create|Edit" }, 
    new[] { "MvcMusicStore.Controllers" });

Since Delete, Details and Edit actions take an id parameter of the same type (Int32) only one route is created that can handle those actions. Keeping the number of routes to a minimum makes route matching more efficient.

Note that Edit is also listed in the second route, because there's also an Edit action that takes no parameters. The order of these routes affects URL generation. For example,

Url.Action("Edit", "StoreManager", new { id = 1 }) returns "/StoreManager/Edit/1",

but if you switch the order

Url.Action("Edit", "StoreManager", new { id = 1 }) returns "/StoreManager/Edit?id=1" (note id in query string).

MvcCodeRouting knows how to order routes to avoid URL generation issues.

Using constraints for the action token avoids route conflicts. MvcCodeRouting also uses constraints for action parameters, which you can override on a per-parameter or per-site basis. Constraining also helps keeping bad URLs out, e.g. /StoreManager/Edit/foo doesn't match any route.

3. Custom routes

Now that we have conventional routes automatically created for us let's see how we can configure more customized routes. Let's change Store/Details/{id} to a more SEO friendly format, like p/{id}/{slug}.

This is the current action code:

public ActionResult Details(int id)
{
   var album = storeDB.Albums.Find(id);

   return View(album);
}

We'll change it to this:

[CustomRoute("~/p/{id}/{slug}")]
public ActionResult Details([FromRoute]int id, [FromRoute]string slug = null)
{
   var album = storeDB.Albums.Find(id);

   if (album != null
      && album.Title != slug) {
      return RedirectToAction(null, new { id, slug = album.Title });
   }

   return View(album);
}

The use of the CustomRoute attribute should be self explanatory. The FromRoute attribute must be used on route parameters. Optional parameters are used to specify if the corresponding route parameter should be optional. Since we don't have a slug property in our model I'm using Title for now.

This is the resulting route definition:

routes.MapRoute(null, "p/{id}/{slug}", 
    new { controller = @"Store", action = @"Details", slug = UrlParameter.Optional }, 
    new { id = @"0|-?[1-9]\d*" }, 
    new[] { "MvcMusicStore.Controllers" });

As you can see, custom routes are easy.

4. Route formatting

Now that we have SEO friendly routes let's see if we can make our conventional routes look prettier. A very common URL formatting convention is lower case hyphenated, this is how we can an implement it:

routes.MapCodeRoutes(
   rootController: typeof(Controllers.HomeController),
   settings: new CodeRoutingSettings { 
      UseImplicitIdToken = true,
      RouteFormatter = args =>
         Regex.Replace(args.OriginalSegment, @"([a-z])([A-Z])", "$1-$2")
            .ToLowerInvariant()
   }
);

RouteFormatter is a delegate that takes information about a route segment and returns a modified segment. Routes now look like this one:

routes.MapRoute(null, "shopping-cart/{action}/{id}", 
    new { controller = @"ShoppingCart" }, 
    new { action = @"add-to-cart|remove-from-cart", id = @"0|-?[1-9]\d*" }, 
    new[] { "MvcMusicStore.Controllers" });

The beauty of route formatting is that it doesn't affect URL generation. For instance, Url.Action("AddToCart", "ShoppingCart") continues to work, even though the route uses add-to-cart and not AddToCart. Route formatting is easy.

5. Namespaces

Currently, the StoreManager controller only manages Albums, what about the other entities in our application, like Artist and Genre? Let's add actions for those too, but adding them to the StoreManager controller would make it grow too much and make the code hard to maintain, so instead let's create separate controllers in a sub-namespace:

namespace MvcMusicStore.Controllers.StoreManager // <-- Note the sub-namespace
{
   [Authorize(Roles = "Administrator")]
   public class ArtistController : Controller 
   {
      public ActionResult Index() 
      {
         throw new NotImplementedException();
      }

      public ViewResult Details(int id) 
      {
         throw new NotImplementedException();         
      }

      public ViewResult Create() 
      {
         throw new NotImplementedException();
      }
   }

   [Authorize(Roles = "Administrator")]
   public class GenreController : Controller 
   {
      public ActionResult Index() 
      {
         throw new NotImplementedException();
      }

      public ViewResult Details(int id) 
      {
         throw new NotImplementedException();
      }

      public ViewResult Create() 
      {
         throw new NotImplementedException();
      }
   }
}

The routes created for these controllers are:

routes.MapRoute(null, "store-manager/artist/details/{id}", 
    new { controller = @"Artist", action = @"Details" }, 
    new { id = @"0|-?[1-9]\d*" }, 
    new[] { "MvcMusicStore.Controllers.StoreManager" });

routes.MapRoute(null, "store-manager/genre/details/{id}", 
    new { controller = @"Genre", action = @"Details" }, 
    new { id = @"0|-?[1-9]\d*" }, 
    new[] { "MvcMusicStore.Controllers.StoreManager" });

routes.MapRoute(null, "store-manager/artist/{action}", 
    new { controller = @"Artist", action = @"index" }, 
    new { action = @"index|create" }, 
    new[] { "MvcMusicStore.Controllers.StoreManager" });

routes.MapRoute(null, "store-manager/genre/{action}", 
    new { controller = @"Genre", action = @"index" }, 
    new { action = @"index|create" }, 
    new[] { "MvcMusicStore.Controllers.StoreManager" });

Unlike areas, there's no limit to the depth of namespaces you can use with MvcCodeRouting. There's also support for namespace-aware views location. For example, views for the MvcMusicStore.Controllers.StoreManager.Artist controller can be located in ~/Views/StoreManager/Artist/.

Conclusions

MvcCodeRouting is an attempt to make you almost completely forget about route management and routing issues, a routing-based URL to code mapping solution. Give it a try!

What's really new in ASP.NET MVC 4 (not much)

2012-08-17T21:51:00.000-04:00

Attributes

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Class, AllowMultiple=false, Inherited=true)]
public sealed class AllowAnonymousAttribute : Attribute

This new attribute allows you to secure an entire controller using AuthorizeAttribute but still expose individual actions for anonymous access.

[AttributeUsage(AttributeTargets.Method, AllowMultiple=false, Inherited=true)]
public sealed class HttpHeadAttribute : ActionMethodSelectorAttribute

[AttributeUsage(AttributeTargets.Method, AllowMultiple=false, Inherited=true)]
public sealed class HttpOptionsAttribute : ActionMethodSelectorAttribute

[AttributeUsage(AttributeTargets.Method, AllowMultiple=false, Inherited=true)]
public sealed class HttpPatchAttribute : ActionMethodSelectorAttribute

These new attributes provide the same functionality as HttpPost, HttpGet, HttpPut and HttpDelete, but for HEAD, OPTIONS and PATCH HTTP methods. HttpHead is in my view useless, since the whole point of the HEAD method is the check if a GET request would succeed, therefore the same action that handles GET should handle HEAD. An HttpGetHead attribute would have been more useful, fortunately it's easy to implement.

New HtmlHelper extensions

Html.DisplayName(string expression);
Html.DisplayNameFor(Expression<Func<TModel, TValue>> expression);

These extensions are used to get the display name of a type or property, before you had to get an instance of the ModelMetadata class for the type or property, now it's conveniently available from HtmlHelper.

Html.TextBox(string name, object value, string format);
Html.TextBox(string name, object value, string format, IDictionary<string, object> htmlAttributes);
Html.TextBox(string name, object value, string format, object htmlAttributes);
Html.TextBoxFor(Expression<Func<TModel, TProperty>> expression, string format);
Html.TextBoxFor(Expression<Func<TModel, TProperty>> expression, string format, IDictionary<string, object> htmlAttributes);
Html.TextBoxFor(Expression<Func<TModel, TProperty>> expression, string format, object htmlAttributes);

These new overloads for rendering textboxes include an additional format parameter, which internally call String.Format to customize how the value is rendered.

Html.Label(string expression, IDictionary<string, object> htmlAttributes);
Html.Label(string expression, object htmlAttributes);
Html.Label(string expression, string labelText, IDictionary<string, object> htmlAttributes);
Html.Label(string expression, string labelText, object htmlAttributes);
Html.LabelFor(Expression<Func<TModel, TValue>> expression, IDictionary<string, object> htmlAttributes);
Html.LabelFor(Expression<Func<TModel, TValue>> expression, object htmlAttributes);
Html.LabelFor(Expression<Func<TModel, TValue>> expression, string labelText);
Html.LabelFor(Expression<Func<TModel, TValue>> expression, string labelText, IDictionary<string, object> htmlAttributes);
Html.LabelFor(Expression<Func<TModel, TValue>> expression, string labelText, object htmlAttributes);
Html.LabelForModel(IDictionary<string, object> htmlAttributes);
Html.LabelForModel(object htmlAttributes);
Html.LabelForModel(string labelText, IDictionary<string, object> htmlAttributes);
Html.LabelForModel(string labelText, object htmlAttributes);

These new overloads for rendering labels include the standard htmlAttributes parameter, it was simply an oversight that these were not included in v3.

Html.Id(string name);
Html.IdFor(Expression<Func<TModel, TProperty>> expression);
Html.IdForModel();
Html.Name(string name);
Html.NameFor(Expression<Func<TModel, TProperty>> expression);
Html.NameForModel();

These new extensions render the full id or name from a partial name or expression. This functionality was available in v3, but now it's much easier to call on HtmlHelper.

Html.Value(string name);
Html.Value(string name, string format);
Html.ValueFor(Expression<Func<TModel, TProperty>> expression);
Html.ValueFor(Expression<Func<TModel, TProperty>> expression, string format);
Html.ValueForModel();
Html.ValueForModel(string format);

These new extensions render the value of a property from model state, view data or view model.

public string FormatValue(object value, string format);
public IHtmlString Raw(object value);

These are not extensions but instance methods of HtmlHelper. FormatValue simply calls String.Format, and the new Raw overload allows you to pass any value without having to convert to string.

New UrlHelper methods

public string HttpRouteUrl(string routeName, object routeValues);
public string HttpRouteUrl(string routeName, RouteValueDictionary routeValues);

These new methods are used to generate URLs for Web Api routes. Apparently, Web Api routes are "special" and cannot be matched using UrlHelper.RouteUrl. Internally, these methods add an "httproute" entry to routeValues, and the GetVirtualPath method of the Web Api route classes (there's more than one) return null unless you include "httproute" in the values. What a mess...

New Controller properties

public AsyncManager AsyncManager { get; }
public ProfileBase Profile { get; }
public ViewEngineCollection ViewEngineCollection { get; set; }
protected virtual Boolean DisableAsyncSupport { get; }

Profile is just a shortcut to this.HttpContext.Profile. ViewEngineCollection is just a shortcut to ViewEngines.Engines. The new async related properties are there because now all controllers are executed asynchronously by default.

That's about it

There are some other new types, some new members, some obsoleted members, some deleted or type-forwarded types, but I don't want to bore you and myself to death. There's nothing new in MVC 4, except for...

The real new features

In reality there are only 2 new features, Display Modes and returning Task from an async action.

As I pointed out before, Web Api is not MVC, it doesn't depend on MVC, it doesn't even depend on ASP.NET. Bundling and minification can be used on any ASP.NET project. jQuery UI, Entity Framework, OpenID, all separate libraries. This release feels more like v3.1 than v4.

MVC and Web Api

The reason because MVC and Web Api are released and distributed together is..., well..., I have no idea why. There's no technical reason behind that decision. I guess Microsoft thought people would probably use both on the same project. There's no Web Api project template on Visual Studio, you have to create an MVC project to use Web Api.

One year from now Microsoft will be eager to release Web Api v2 after recieving massive feedback and bug reports, will there be a new major release for MVC? I'm not sure, maybe they'll release a new major version, but with only a couple of new features just like this one. MVC is now on maintenence mode, just like Web Forms and LINQ to SQL. MVC 3 was already an excelent, mature and extensible framework. It's not up to Microsoft, but it's up to the community to build more cool stuff on top of it.

Update: The ASP.NET team have confirmed my suspicion in their roadmap:

No new functionality will be added to the runtime components. Instead the area of focus will be enabling a richer set of templates for building various types of web applications developers need in addition to updating the current templates.

Implementing a Delete button in ASP.NET MVC

2012-08-11T18:17:00.000-04:00

I've been reading the HTML 4 and 5 specs lately, more specifically about forms, and learned something new. I knew a button could have a name and value, what I didn't know is that a button is considered a successful control, which means its data is sent to the server, only if the form submission is triggered by that button. This is a cool feature that allows your server logic to know which button was clicked and perform different operations based on that. A very common scenario is implementing a delete button.

In the past I've done this in a number of ways: AJAX, a separate form, etc. Usually, people use a different POST action for delete, e.g.

public ActionResult Edit(int id) {
   ...
}

[HttpPost]
public ActionResult Delete(int id) {
   ...
}

Taking advantage of the framework's support for X-HTTP-Method-Override, you can implement a delete button, on the same form, that POSTs to the same URL...

public ActionResult Edit(int id) {
   ...
}

[HttpDelete]
public ActionResult Edit(int id, string foo) {
   ...
}

...like this:

@using (Html.BeginForm()) {
   <button>Save</button>
   <button name="X-HTTP-Method-Override" value="DELETE">Delete</button>
}

Easy, right? X-HTTP-Method-Override is sent only when you click the delete button. You can also include onclick="return confirm('Are you sure?')" for a confirmation dialog.

There's one catch though, validation. If the form is not valid it won't submit. This is rarely an issue, but it can happen if the user made some changes that leaves the form in an invalid state and then decides to delete the resource. HTML5 supports this scenario using the formnovalidate="formnovalidate" attribute on the button. The jQuery validation plugin doesn't seem to recognize this attribute, but you can achieve the same behavior using the cancel class on the button. So, this is the final version of our 100% declarative delete button:

<button name="X-HTTP-Method-Override" value="DELETE" formnovalidate="formnovalidate" class="cancel" 
   onclick="return confirm('Are you sure?')">Delete</button>

Patterns for ASP.NET MVC Plugins: View Models

2012-07-24T00:01:00.000-04:00

The goal of these patterns is to provide a consistent experience for plugin consumers (application developers), minimize the amount of configuration required to get a plugin working in the host application and maximize the plugin's flexibility to customize it's behavior.

This is the second post of the series, see also the other posts:

Routes, Controllers and Configuration
View Models
Demo: Implementing a contact form plugin

Basic patterns

Always use strongly-typed view models. Don't use ViewData, ViewBag or a dynamic/anonymous object, always create a specialized view model class for each view. Application developers will appreciate it when customizing views.

Name view models after the view plus the "ViewModel" suffix. e.g. for the Index view create an IndexViewModel class. Although ViewModel is a long suffix, it makes it very clear for the developer to understand what's the purpose of the class, and to differentiate from other kinds of models the plugin might have. If you have more than one controller use the controller name as prefix, e.g. FooIndexViewModel.

Customize display names using DisplayNameAttribute instead of DisplayAttribute. There are two ways of customizing the display names of types and properties. You can use the Name property of the DisplayAttribute or you can use the DisplayNameAttribute, the framework recognizes both in that order. You should use DisplayNameAttribute because it's specifically design for that purpose (DisplayAttribute has many other properties), and more importantly because DisplayAttribute is sealed and DisplayNameAttribute isn't. If some component needs to customize how display names are computed subclassing DisplayNameAttribute is the only way, a common example is reading display names from resource files for localization. You can still use DisplayAttribute for all the other properties it has, just don't use Name. Update: I was under the impression that DisplayAttribute did not support localization, but I was wrong. DisplayAttribute fixes two issues about DisplayNameAttribute: 1) It supports localization, 2) It can be applied to fields (e.g. enums members). So, if your plugin targets .NET 4 or higher you should use DisplayAttribute. If you care about maximum compatibility, e.g. with libraries that target .NET 2-3.5, or that maybe recognize only one of them, you should use both.

Set Display(Order) for all properties. When you subclass a model to add more properties, these added properties will appear at the top of the form, before the properties from the base class. Normally you want fields in a form to be sorted by importance, so in most cases it would make more sense to see the subclass properties at the bottom. Since that is not the case you should explicitly set Display(Order) on all properties. Note that having more than one property with the same Order value is allowed, in that case the subclass property also goes first.

Use the DataTypeAttribute when appropiate. See if your properties are used for values that can be represented by one of the members in the DataType enumeration. Common cases are Password, MultilineText and EmailAddress. Setting this attribute makes it easier to customize display and editor templates for each of these types of values.

View Models, Input Models and Output Models

I want to make a distinction between the different kinds of models, based on their purpose. A view model is a model for the view, it defines the data that the view needs and uses, nothing less nothing more. An input model defines the data that an action takes as input, e.g. from a form submission. An output model defines the data that is the result of an action, e.g. search results. Some actions have inputs but no outputs (e.g. actions that redirect), some actions have outputs but no inputs, and some have both inputs and outputs.

Define separate classes for input and output models, plus a view model class that reference the other two. Instead of defining a single view model class that contain both input and output properties define a class for each of these types of models, plus a view model class with an InputModel property (for actions that have inputs) and an OutputModel property (for actions that have outputs).

Although the framework has a BindAttribute and several [Try]UpdateModel overloads where you can specify which input properties should be bound, or which output properties should not be bound, using it means that every time you want to extend an input or output model you would have to update the action code, which is not an option for precompiled plugins. The following sections talk about input and output model extensibility.

Another reason for having separate input and output models is editor and display templates. Application developers should be able to customize editor and display templates for specific types without having to override an entire view to do so.

Input Models

Name input models after the action method name plus the "Input" suffix. e.g. for the ChangeEmail action create the ChangeEmailInput input model. Notice I said action method name instead of action name, sometimes action names are shortened (e.g. using the ActionNameAttribute) or changed in some way to make the URL suit a particular style. The name of input models should be meaningful to application developers and don't need to match the action URL. If you have more than one controller use the controller name as prefix, e.g. AccountChangeEmailInput.

If you have Create and Update actions that have identical input models define a single input model named after the resource plus the "Edit" suffix. e.g. ProductEdit. This one is for actions that are more "resource oriented". If one of the models contains a subset of the other consider making one inherit the other to avoid having duplicate properties (defining identical properties is not the main issue, is more about all the metadata you put on them via attributes).

Don't include unique identifier properties. Input models have no identity, if you are using an input model to provide changes to some existing resource pass in the resource identifier as a separate argument. For example, let's say we have an action to edit a single product:

[HttpPost]
public ActionResult Edit(int id, ProductEdit input) {
   ...
}

The id parameter identifies the product, and the ProductEdit input model defines the properties that can be changed:

public class ProductEdit {
   public string Name { get; set; }
   public decimal UnitPrice { get; set; }
}

If you want to display the id on the view you should include it in an output model.

Create an HtmlHelper<TModel> instance for form rendering, where TModel is the input model type. It's common to use an input model as view model to provide strongly-typed HTML helpers for form controls and validation messages, e.g. Html.EditorFor(p => p.SomeProperty). By having a separate input model type that the view model includes in a property, strongly-typed HTML helper calls are changed to something like Html.EditorFor(p => p.InputModel.SomeProperty), which means all form fields will have the "InputModel." prefix. You can avoid this by creating an HtmlHelper<TModel> instance, where TModel is the input model type. The following is an extension method for this purpose:

public static class HtmlHelperFactoryExtensions {

   public static HtmlHelper<TModel> HtmlHelperFor<TModel>(this HtmlHelper htmlHelper) {
      return HtmlHelperFor(htmlHelper, default(TModel));
   }

   public static HtmlHelper<TModel> HtmlHelperFor<TModel>(this HtmlHelper htmlHelper, TModel model) {
      return HtmlHelperFor(htmlHelper, model, null);
   }

   public static HtmlHelper<TModel> HtmlHelperFor<TModel>(this HtmlHelper htmlHelper, TModel model, string htmlFieldPrefix) {

      var viewDataContainer = CreateViewDataContainer(htmlHelper.ViewData, model);

      TemplateInfo templateInfo = viewDataContainer.ViewData.TemplateInfo;

      if (!String.IsNullOrEmpty(htmlFieldPrefix))
         templateInfo.HtmlFieldPrefix = templateInfo.GetFullHtmlFieldName(htmlFieldPrefix);

      ViewContext viewContext = htmlHelper.ViewContext;
      ViewContext newViewContext = new ViewContext(viewContext.Controller.ControllerContext, viewContext.View, viewDataContainer.ViewData, viewContext.TempData, viewContext.Writer);

      return new HtmlHelper<TModel>(newViewContext, viewDataContainer, htmlHelper.RouteCollection);
   }

   static IViewDataContainer CreateViewDataContainer(ViewDataDictionary viewData, object model) {

      var newViewData = new ViewDataDictionary(viewData) {
         Model = model
      };

      newViewData.TemplateInfo = new TemplateInfo { 
         HtmlFieldPrefix = newViewData.TemplateInfo.HtmlFieldPrefix 
      };

      return new ViewDataContainer {
         ViewData = newViewData
      };
   }

   class ViewDataContainer : IViewDataContainer {
         
      public ViewDataDictionary ViewData { get; set; }
   }
}

This is how you use it in a view:

@using (Html.BeginForm()) {
   var inputHtml = Html.HtmlHelperFor(Model.InputModel);
   @inputHtml.EditorForModel()
   <input type="submit"/>
}

Use ViewData to pass a [Multi]SelectList instance for multiple choice controls. This is one case where using ViewData has benefits. It provides an out-of-band way of making a [Multi]SelectList available to multiple choice HTML helpers such as DropDownList, which means the view that calls the helper does not need to provide it as argument or can just pass null. To avoid losing type safety you can use the following method:

void SetSelectList<TModel, TProperty>(TModel model, Expression<Func<TModel, TProperty>> propertySelector, MultiSelectList list) {
   this.ViewData[ExpressionHelper.GetExpressionText(propertySelector)] = list;
}

This is how you use it:

SetSelectList(model, m => m.Country, selectList);

Provide a virtual method for the creation of input models, and name it after the type name plus the "Create" prefix. e.g.

public virtual ChangeEmailInput CreateChangeEmailInput() {
   return new ChangeEmailInput();
}

This method should be defined in the controller dependency that uses the input model. By overriding this method you can return a subclass of the input model.

Provide a virtual method for the initialization of input models, and name it after the type name plus the "Initialize" prefix. e.g.

protected virtual void InitializeChangeEmailInput(ChangeEmailInput input) { }

This method should be defined in the controller dependency that uses the input model. This method is for providing default or initial values to form fields. You can also define additional parameters, e.g. if you want to initialize with persisted values. If the input model is used in more than one action append "For" to the method name plus the name of the method that uses the input model, e.g. InitializeProductEditForCreate, InitializeProductEditForUpdate.

Use the virtual modifier on all input model properties. This allows the subclass to add or override attributes.

Use a model binding implementation that supports subclassing. Unfortunately, the [Try]UpdateModel methods provided by the framework require that you explicitly declare the type you are binding at compile time, and if you attempt to bind a subclass instance the subclass properties are ignored. Even though they closed the issue claiming it's by design, let them know it's a bad design. Use the following code to workaround this issue:

static class ModelBinderUtil {

   public static bool TryUpdateModel(object model, Controller controller) {

      if (model == null) throw new ArgumentNullException("model");
      if (controller == null) throw new ArgumentNullException("controller");

      Type modelType = model.GetType();

      ModelBinders.Binders
         .GetBinder(modelType)
         .BindModel(controller.ControllerContext, new ModelBindingContext {
            ModelMetadata = ModelMetadataProviders.Current.GetMetadataForType(() => model, modelType),
            ModelState = controller.ModelState,
            ValueProvider = controller.ValueProvider
         });

      return controller.ModelState.IsValid;
   }
}

Set Response.StatusCode to 400 (Bad Request) if model binding fails. Although users don't know or care about the status codes, it's important to set an error status code for AJAX clients. Even if your plugin does not implement AJAX forms, the plugin consumer might want to enhance the plugin with AJAX submissions, and the only (appropriate) way to know if the request succeeded or not is by examining the response status code.

Output Models

Name output models after the action method name plus the "Result" suffix. e.g. SearchResult. If you have more than one controller use the controller name as prefix, e.g. ProductsSearchResult.

Consider using view model properties for metadata and presentation data. It's usually cleaner to pass things like links, titles, messages or other unrelated pieces of data that the view needs, as properties of the view model. This might be data that complement the output model, but created in a different layer of the plugin (e.g. the "Cancel" link of a form). It can also be presentation-specific data, such as the active tab in a tabbed interface. In other words, output models should be used for "business" or "domain" data, and view models for application or presentation data. It's up to the plugin developer to decide where to draw the line, but should always prioritize usability from the application developer's perspective.

Provide a virtual method for the creation of output models, and name it after the type name plus the "Create" prefix. e.g.

protected virtual SearchResult CreateSearchResult() {
   return new SearchResult();
}

This method should be defined in the controller dependency that uses the output model. By overriding this method you can return a subclass of the output model.

Provide a virtual method for the binding of output models, and name it after the type name plus the "Bind" prefix. e.g.

protected virtual void BindSearchResult(SearchResult result, object data) { }

This method should be defined in the controller dependency that uses the output model. The type of the second parameter is implementation-defined.

Conclusions

Good view model design can make a great difference in the plugin's customizability. We've covered ways to customize the data that comes in and out of the plugin, their presentation and validation metadata. Naming patterns are also very important for usability, it makes it easier for application developers to find and discover the types they need to use.

Tying it all together

On the next post I'm going to dissect a sample plugin that implements most of the patterns presented on this series so far. Stay tuned.

Patterns for ASP.NET MVC Plugins: Routes, Controllers and Configuration

2012-06-11T00:43:00.000-04:00

The goal of these patterns is to provide a consistent experience for plugin consumers (application developers), minimize the amount of configuration required to get a plugin working in the host application and maximize the plugin's flexibility to customize it's behavior.

This post focuses on routes, controllers and configuration. Subsequent posts will focus on other aspects, such as views, models, localization, etc.

Routes, Controllers and Configuration
View Models
Demo: Implementing a contact form plugin

Routes

Don't require any custom route configuration, make it an option for prettier URLs. In practice this means the plugin shouldn't depend or assume a specific route configuration:

Don't refer to named routes e.g. Url.RouteUrl("routeName")
Don't hardcode URLs e.g. return Redirect("/Foo/Bar")

Don't add routes to RouteTable.Routes. The application developer should decide how to expose the plugin, if at all. The plugin should work fine with the default route {controller}/{action}/{id}.

Provide sample code of custom routes the application developer can copy and paste into the host application for prettier URLs.

Controllers

Make controllers public so they can be found by the DefaultControllerFactory.

Name controllers with common, widely used names. If the plugin is about authentication, AccountController; A blog, BlogController; A forum, ForumController. This makes the plugin default route friendly.

Use a parameter named 'id' for unique identifier inputs. Again, make the inputs default route compatible.

Minimize the number of controllers. Ideally, the plugin should consist of a single controller. If more than one controller is used, put them all in the same namespace.

Provide a default constructor so they can be instantiated by DefaultControllerFactory. Beginners are usually not familiar nor comfortable with container assisted dependency injection (DI). The next section explains an alternate way of providing dependencies that doesn't require a DI container.

Provide constructors that take dependencies as arguments for applications already using a DI container.

There are two kinds of dependencies: abstract and concrete. These can also be viewed as required and optional. Abstract dependencies represent functionality that the application developer is required to implement before they can use the plugin. These take the form of abstract types or interfaces. Concrete dependencies represent functionality already provided by the plugin, but that the application developer has the option to customize. These take the form of non-abstract, non-static classes with virtual public and/or protected members.

Provide a constructor that take all abstract and concrete dependencies. Put abstract dependencies first, then concrete dependencies. Many DI containers use by default the constructor with most parameters. By having a constructor that take all dependencies, the application developer will have the option to subclass and customize any/all concrete dependencies with minimum configuration. Do not provide another constructor with the same number of parameters.

Provide a constructor that take all abstract dependencies and none of the concrete dependencies. Some DI containers (like Autofac) use by default the constructor with the most parameters they know how to resolve. Don't force developers to register concrete dependencies, make that an option.

Provide other constructors that take all abstract dependencies and some of the concrete dependencies. Don't force developers to register all concrete dependencies, if they only want to customize a subset of them.

The following is an example that follow these recommendations, AccountRepository and PasswordService are abstract (required) dependencies, and FormsAuthenticationService is concrete (optional).

public class AccountController : Controller {

   readonly AccountService service;

   public AccountController() 
      : this(new AccountService()) { }

   public AccountController(AccountRepository repository, PasswordService passwordService)
      : this(new AccountService(repository, passwordService)) { }

   public AccountController(AccountRepository repository, PasswordService passwordService, FormsAuthenticationService formsAuthService) 
      : this(new AccountService(repository, passwordService, formsAuthService)) { }

   private AccountController(AccountService service) {
      this.service = service;
   }
}

Configuration

Provide a class for the plugin's configuration settings. Make it an instance class with instance properties, not static, not singleton.

Use the 'Configuration' data token to accept an instance of the configuration class. Here's an example:

public class BlogController : Controller {
   
   BlogConfiguration config;

   protected override void Initialize(RequestContext requestContext) {
      
      base.Initialize(requestContext);

      this.config = requestContext.RouteData.DataTokens["Configuration"] as BlogConfiguration 
         ?? new BlogConfiguration();
   }
}

This is what the route registration could look like:

routes.MapRoutes(null, "Blog/{action}/{id}"
   { controller = "Blog", action = "Index", id = UrlParameter.Optional },
   new[] { "CoolBlog.Controllers" })
   .DataTokens["Configuration"] = new BlogConfiguration {
      // Set config properties
   };

MvcCodeRouting also follows this pattern, with the Configuration setting:

route.MapCodeRoutes(
   baseRoute: "Blog",
   rootController: typeof(CoolBlog.Controllers.BlogController),
   settings: new CodeRoutingSettings {
      Configuration = new CoolBlog.BlogConfiguration {
         // Set config properties
      }
   }
);

Provide Func<> properties for each dependency, and name them with the "Resolver" suffix. Here's an example:

var config = new CoolBlog.BlogConfiguration {
   RepositoryResolver = () => new MyBlogRepository()
};

A DI container can also be used to resolve dependencies, if object composition or lifetime management is required:

var config = new CoolBlog.BlogConfiguration {
   RepositoryResolver = () => container.Resolve<CoolBlog.BlogRepository>()
};

The advantage of associating the plugin's configuration instance, that include resolver properties for DI, with the plugin's route is that you can use more than one plugin instance per application, each with different configuration settings.

Conclusions

This post deals with what I think are the most important aspects of plugin development for ASP.NET MVC: routes, controllers and configuration. The MVC framework itself has a number of conventions that application developers are accustomed to; plugin developers should adhere to these conventions. This post proposes patterns that do not require a special infrastructure (e.g. common library for plugins) to work. Instead, it uses what the framework already provides. Plugins are just controllers exposed via routes, just like anything else in the host application. Hopefully these patterns will help you build plugins that are portable, flexible and easy to configure.

Putting ASP.NET Routing to test

2012-04-11T16:33:00.000-03:00

This post is not about unit-testing your routes, it's about testing the features of ASP.NET Routing to verify and acquire an in-depth knowledge of it's functionality.

Having used ASP.NET MVC for a long time I thought I had a complete understanding about how Routing worked, but the other day I wasn’t sure about something that thought should work and took for granted. So I decided to write some tests to clear my doubts and hopefully learn something new.

Some of these tests verify things you probably already know, if something is too obvious you can just skip to the next one. You don't need to follow the test code, but after each test I've included information on how to take advantage or how to avoid common issues of the tested functionality.

Test class setup

RouteCollection routes;
UrlHelper Url;

[TestInitialize]
public void Init() {
         
   this.routes = new RouteCollection();

   var httpContextMock = new Mock<HttpContextBase>();
   httpContextMock.Setup(c => c.Request.ApplicationPath).Returns("");
   httpContextMock.Setup(c => c.Response.ApplyAppPathModifier(It.IsAny<string>()))
      .Returns<string>(s => s);

   var routeData = new RouteData();
   var requestContext = new RequestContext(httpContextMock.Object, routeData);
         
   this.Url = new UrlHelper(requestContext, routes);
}

I'll be using UrlHelper to generate URLs because it has a nice API, but that doesn’t mean what I’m testing is specific to MVC, you could write the same tests using RouteCollection.GetVirtualPath.

Name is optional

[TestMethod]
public void NameIsOptional() { 
         
   routes.Clear();
   routes.MapRoute(null, "");
}

The route name is completely optional. I used to waste time trying to come up with a consistent naming convention and didn’t even use them.

Parameters are required by default

[TestMethod]
public void ParametersAreRequiredByDefault() {

   routes.Clear();
   routes.MapRoute(null, "{a}");

   Assert.IsNull(Url.RouteUrl(new { }));
   Assert.AreEqual(Url.RouteUrl(new { a = "b" }), "/b");

   var httpContextMock = new Mock<HttpContextBase>();
   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/");

   Assert.IsNull(routes.GetRouteData(httpContextMock.Object));

   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/b");

   Assert.IsNotNull(routes.GetRouteData(httpContextMock.Object));
}

You should know this one, so I won’t say much about it. When you include a parameter in the URL pattern, that parameter is required for both incoming requests and URL generation.

In case you are not familiar with UrlHelper.RouteUrl, Url.Action("Index", "Home") is equivalent to Url.RouteUrl(new { action = "Index", controller = "Home" }). I'm not using action and controller parameters to emphasize that: A. the tests are not specific to MVC; B. action and controller parameters are not special in any way.

Default value makes parameter optional

[TestMethod]
public void DefaultValueMakesParameterOptional() {

   routes.Clear();
   routes.MapRoute(null, "{a}", new { a = "b" });

   Assert.AreEqual(Url.RouteUrl(new { }), "/");

   var httpContextMock = new Mock<HttpContextBase>();
   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/");

   Assert.IsNotNull(routes.GetRouteData(httpContextMock.Object));
}

The title says it all. You should know this one also.

Can use null or empty string for parameter with default value

[TestMethod]
public void CanUseNullOrEmptyStringForParameterWithDefaultValue() {

   routes.Clear();
   routes.MapRoute(null, "{a}", new { a = "b" });

   Assert.AreEqual(Url.RouteUrl(new { a = (string)null }), "/");
   Assert.AreEqual(Url.RouteUrl(new { a = "" }), "/");
}

In the previous test we verified that when a parameter is optional you can omit its value in URL generation. Using null or an empty string also works.

I like to take advantage of this one when generating URLs that refer to the default action of a controller, for example Url.Action("") or Url.Action("", "Account"). Note that for these to work the route must include the {action} token, I explain why on the next test.

Cannot use null or empty string for default value without parameter

[TestMethod]
public void CannotUseNullOrEmptyStringForDefaultValueWithoutParameter() {

   routes.Clear();
   routes.MapRoute(null, "a", new { b = "c" });

   Assert.IsNull(Url.RouteUrl(new { b = (string)null }));
   Assert.IsNull(Url.RouteUrl(new { b = "" }));
}

This one is interesting. If you have a default value without a corresponding parameter, using null or empty string for that value in URL generation does not match the route.

This is common when you have a route that is specific to a single controller or action, e.g.

routes.MapRoute(null, "Products/Search",
   new { controller = "Products", action = "Search" });

Value must match default value without parameter or be omitted

[TestMethod]
public void ValueMustMatchDefaultValueWithoutParameterOrBeOmitted() {

   routes.Clear();
   routes.MapRoute(null, "a", new { b = "c" });

   Assert.AreEqual(Url.RouteUrl(new { b = "c" }), "/a");
   Assert.AreEqual(Url.RouteUrl(new { }), "/a");
}

In the previous test we verified that using null or empty string does not work. Omitting the value or using the same value as the default works.

Going back to the "Products/Search" example, this test verifies that controller and action are constants that can either be omitted or provided with the same value to match the route. This is a nice feature that frees us from having to provide constraints for those values, e.g.

routes.MapRoute(null, "Products/Search",
   new { controller = "Products", action = "Search" },
   new { controller = "Products", action = "Search" }); // Constraints are not needed!

Constraint limits the value-space of a parameter

[TestMethod]
public void ConstraintLimitsTheValueSpaceOfParameter() {

   routes.Clear();
   routes.MapRoute(null, "{a}", new { }, new { a = "b|c" });

   Assert.AreEqual(Url.RouteUrl(new { a = "b" }), "/b");
   Assert.AreEqual(Url.RouteUrl(new { a = "c" }), "/c");
   Assert.IsNull(Url.RouteUrl(new { a = "d" }));

   var httpContextMock = new Mock<HttpContextBase>();
   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/b");

   Assert.IsNotNull(routes.GetRouteData(httpContextMock.Object));

   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/c");

   Assert.IsNotNull(routes.GetRouteData(httpContextMock.Object));

   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/d");

   Assert.IsNull(routes.GetRouteData(httpContextMock.Object));
}

You know this one. String constraints are treated as regular expressions, which work on both incoming request and URL generation. You can also provide an IRouteConstraint instance, which gives you the option to choose when to apply it, incoming request, URL generation or both.

Constraint tests the whole value

[TestMethod]
public void ConstraintTestsTheWholeValue() {
         
   routes.Clear();
   routes.MapRoute(null, "{a}", new { }, new { a = "b" });

   Assert.AreEqual(Url.RouteUrl(new { a = "b" }), "/b");
   Assert.IsNull(Url.RouteUrl(new { a = "b2" }));

   var httpContextMock = new Mock<HttpContextBase>();
   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/b");

   Assert.IsNotNull(routes.GetRouteData(httpContextMock.Object));

   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/b2");

   Assert.IsNull(routes.GetRouteData(httpContextMock.Object));
}

This is a nice feature. Whatever constraint you provide, the runtime wraps it in ^(yourconstraint)$ for you, so it matches the whole value and not just a portion.

Constraint for optional parameter should match an empty string if default value is empty string

[TestMethod]
public void ConstraintForOptionalParameterShouldMatchAnEmptyStringIfDefaultValueIsEmptyString() {

   routes.Clear();
   routes.MapRoute(null, "{a}", new { a = "" }, new { a = "b" });

   Assert.IsNull(Url.RouteUrl(new { a = "" }));

   var httpContextMock = new Mock<HttpContextBase>();
   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/");

   Assert.IsNull(routes.GetRouteData(httpContextMock.Object));

   //--------------------------------------

   routes.Clear();
   routes.MapRoute(null, "{a}", new { a = "" }, new { a = "(b)?" });

   Assert.AreEqual(Url.RouteUrl(new { a = "" }), "/");

   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/");

   Assert.IsNotNull(routes.GetRouteData(httpContextMock.Object));

   //--------------------------------------

   routes.Clear();
   routes.MapRoute(null, "{a}", new { a = "b" }, new { a = "b" });

   Assert.AreEqual(Url.RouteUrl(new { a = "" }), "/");

   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/");

   Assert.IsNotNull(routes.GetRouteData(httpContextMock.Object));
}

This one is in my view a design oversight, but not a big deal nonetheless. If you have a constraint for an optional parameter with an empty string default value, that constraint should match an empty string in case a value for that parameter is not provided. So, for instance if you have:

routes.MapRoute(null, "Products/Browse/{sort}",
   new { controller = "Products", action = "Browse", sort = "" },
   new { sort = "popular|date" }); // Constraint should be "(popular|date)?"

If a value for sort is not provided the default value is used, and the constraint "popular|date" does not match an empty string, so it should be "(popular|date)?". This also applies if the default value is UrlParameter.Optional, or any value that returns an empty string from the ToString() method. Ideally, the constraint would be ignored when the default value is an empty string.

You won’t run into this issue for controller and action parameters, because you always provide non-empty defaults for those.

Current request values are used as defaults

[TestMethod]
public void CurrentRequestValuesAreUsedAsDefaults() {

   routes.Clear();
   routes.MapRoute(null, "{a}");

   var routeData = new RouteData {
      Values = { 
         { "a", "x" },
      }
   };

   var requestContext = new RequestContext(this.Url.RequestContext.HttpContext, routeData);
   var Url = new UrlHelper(requestContext, routes);

   Assert.AreEqual(Url.RouteUrl(new { }), "/x");
}

You can omit values when generating URLs, even for required parameters, and routing will use the current request values.

UrlHelper.Action uses the current request controller and action values as defaults

[TestMethod]
public void UrlHelperActionUsesTheCurrentRequestControllerAndActionValuesAsDefaults() {

   var routeData = new RouteData {
      Values = { 
         { "controller", "b" },
         { "action", "c" }
      }
   };

   var requestContext = new RequestContext(this.Url.RequestContext.HttpContext, routeData);
   var Url = new UrlHelper(requestContext, routes);

   routes.Clear();
   routes.MapRoute(null, "a", new { controller = "b", action = "c" });

   Assert.IsNull(Url.RouteUrl(new { controller = (string)null, action = (string)null }));
   Assert.AreEqual(Url.Action(null), "/a");
   Assert.AreEqual(Url.Action(null, (string)null), "/a");
}

The difference with this test and the previous test is that the previous is about ommiting values, this one is about using null values.

The UrlHelper.Action set of methods take actionName and controllerName string parameters. Calling these methods can be translated to something equivalent to Url.RouteUrl(new { action = actionName, controller = controllerName }). As we verified earlier in Cannot use null or empty string for default value without parameter, using null for actionName and/or controllerName can result in failing to match the desired route. For this reason Url.Action uses the current request controller and action values whenever null is used for actionName and/or controllerName.

This is a nice feature that allows us to generate URLs that refer to the current controller or action, e.g.

Url.Action(null) returns the URL of the current action.
Url.Action("Foo") returns the URL of the Foo action in the current controller.
Url.Action(null, "Bar") returns the URL of the action named like the current action, in the Bar controller.

Routing is case insensitive

[TestMethod]
public void RoutingIsCaseInsensitive() {

   routes.Clear();
   routes.MapRoute(null, "a/{b}", new { a = "A" }, new { b = "xyz" });

   Assert.IsNotNull(Url.RouteUrl(new { a = "a", b = "XYZ" }));

   var httpContextMock = new Mock<HttpContextBase>();
   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/A/XYZ");

   Assert.IsNotNull(routes.GetRouteData(httpContextMock.Object));
}

Everything about routing is case insensitive, literal segments, default values and constraints.

Routes are evaluated in order

[TestMethod]
public void RoutesAreEvaluatedInOrder() {

   routes.Clear();
   routes.MapRoute(null, "{a}/{b}", new { b = "c" });
   routes.MapRoute(null, "{a}");

   var httpContextMock = new Mock<HttpContextBase>();
   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/x");

   Assert.IsTrue(
      Object.ReferenceEquals(
         routes.GetVirtualPath(Url.RequestContext, new RouteValueDictionary(new { a = "x" })).Route, 
         routes.First()
      )
   );

   Assert.IsTrue(
      Object.ReferenceEquals(
         routes.GetRouteData(httpContextMock.Object).Route, 
         routes.First()
      )
   );

   var lastRoute = routes.Last();
   routes.Remove(lastRoute);
   routes.Insert(0, lastRoute);

   Assert.IsTrue(
      Object.ReferenceEquals(
         routes.GetVirtualPath(Url.RequestContext, new RouteValueDictionary(new { a = "x" })).Route,
         routes.First()
      )
   );

   Assert.IsTrue(
      Object.ReferenceEquals(
         routes.GetRouteData(httpContextMock.Object).Route,
         routes.First()
      )
   );
}

So far all tests involved a single route. If you have more than one route, the first one that matches is used, so the route registration order matters.

The larger your application gets, the more routes you'll have, and you'll eventually run into issues where the route matched is not the one you want to match. To solve these issues you have two choices:

1. Changing the order

This tipically means putting the routes with the most parameters/segments at the top.

Pros:

Very easy to do.

Cons:

Can result in having the least used routes at the top, which is inneficient.
Everytime you add a new route you have to test how it affects other routes.

2. Adding constraints

If a parameter should only match a limited set of values you can add a constraint for that parameter.

Pros:

You don't have to worry (so much) about routes order.
You can put the most used routes at the top.
Reject bad URLs earlier.

Cons:

Everytime you create/remove a valid value for the parameter (e.g. add/remove controller/action) you have to update the constraint.

This test has shown us that routing can get tricky. That's why people have created tools to debug these kind of issues, like Route Debugger and Glimpse. Mmm..., if only there was a tool that automated route creation and made me forget about these issues altogether... Wait!, there is!

Literal sub-segment bug

[TestMethod]
public void LiteralSubsegmentBug() {

   routes.Clear();
   routes.MapRoute(null, "_{a}");

   var httpContextMock = new Mock<HttpContextBase>();
   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/_b");

   Assert.IsNotNull(routes.GetRouteData(httpContextMock.Object));

   httpContextMock.Setup(c => c.Request.AppRelativeCurrentExecutionFilePath)
      .Returns("~/__b");

   Assert.IsNull(routes.GetRouteData(httpContextMock.Object));
}

You can read more about this bug here. In short, literal sub-segments don't work very well, specially with string parameters. My recommendation is to use a constraint, and a custom type with a model binder to parse the parameter. For example, let's say you want to implement these URLs:

products/{id}
products/{slug}-{id}

Both should be handled by the same action, the {id} part is required and {slug}- is optional. First, we create a type that holds both pieces of data:

public class SlugIdentifier {

   public const string Pattern = @"((.+)-)?([1-9]\d*)";
   static readonly Regex Regex = new Regex(Pattern);

   public int Id { get; private set; }
   public string Slug { get; private set; }

   public static SlugIdentifier Parse(string identifier) {

      if (identifier == null) throw new ArgumentNullException("identifier");

      Match match = Regex.Match(identifier);

      if (!match.Success)
         throw new ArgumentException("identifier is invalid.", "identifier");

      return new SlugIdentifier(
         Int32.Parse(match.Groups[3].Value),
         match.Groups[2].Value
      );
   }

   public SlugIdentifier(int id, string slug) {
      this.Id = id;
      this.Slug = slug;
   }
}

Implementing the model binder is very easy:

class SlugIdentifierModelBinder : IModelBinder {

   public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext) {
      return SlugIdentifier.Parse(
         (string)bindingContext.ValueProvider.GetValue(bindingContext.ModelName).RawValue
      );
   }
}

And we register it on Application_Start:

void RegisterModelBinders(ModelBinderDictionary binders) {
   binders.Add(typeof(SlugIdentifier), new SlugIdentifierModelBinder());
}

Finally, register the route:

routes.MapRoute(null, "products/{id}",
   new { controller = "Products", Action = "Details" },
   new { id = SlugIdentifier.Pattern });

And we are done!

public ActionResult Details(SlugIdentifier id) {
   ...
}

Two consecutive optional parameters bug

//[TestMethod] // Appears to be fixed in .NET 4.5
public void TwoConsecutiveOptionalParametersBug() {

   routes.Clear();
   routes.MapRoute(null, "a/{b}/{c}", new { b = "", c = "" });

   Assert.IsNotNull(Url.RouteUrl(new { b = "1", c = "2" }));
   Assert.IsNotNull(Url.RouteUrl(new { b = "1" }));
   Assert.IsNull(Url.RouteUrl(new { }));
}

You can read more about this bug here. I was able to reproduce in .NET 4, but not in .NET 4.5, so apparently it’s fixed.

Conclusions

I think I've covered everything you need to know about how routes are matched for incoming requests and URL generation.

Routing is easy, if you have one route. The Routing system itself and ASP.NET MVC offer no help when it comes to detect issues like routes ambiguity. You have three choices: 1. unit-test your routes, 2. use debugging tools, 3. automate route creation.

Thanks for reading!

Web Pages exception in ASP.NET MVC 3 application after installing MVC 4 Beta

2012-02-19T15:00:00.001-03:00

After installing ASP.NET MVC 4 Beta I tried to run one of my MVC 3 applications and got this error:

System.InvalidCastException: [A]System.Web.WebPages.Razor.Configuration.HostSection cannot be cast to [B]System.Web.WebPages.Razor.Configuration.HostSection. Type A originates from 'System.Web.WebPages.Razor, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'Default' at location 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.WebPages.Razor\v4.0_1.0.0.0__31bf3856ad364e35\System.Web.WebPages.Razor.dll'. Type B originates from 'System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' in the context 'Default' at location 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Web.WebPages.Razor\v4.0_2.0.0.0__31bf3856ad364e35\System.Web.WebPages.Razor.dll'.

For some reason the framework was loading version 2.0 of System.Web.WebPages.Razor.dll instead of version 1.0. To fix it I just set webpages:Version to 1.0 in Web.config:

<appSettings>
   <add key="webpages:Version" value="1.0"/>
</appSettings>

ASP.NET MVC 4 Beta: Web API is not MVC

2012-02-18T13:18:00.001-03:00

The ASP.NET MVC 4 Beta release includes a new API called ASP.NET Web API:

ASP.NET Web API is a framework that makes it easy to build HTTP services that reach a broad range of clients, including browsers and mobile devices. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework.

You can find a better description in this post. In short, Web API is WCF Web API rewritten in an MVC-ish way. It takes a lot of ideas from MVC, like Controllers, Routes, Model Metatada, Model Binding, Model Validation, Value Providers, Filter Attributes, etc., and adds WCF Web API features, like OData and non-ASP.NET hosting.

The bad thing is that, even though Web API looks and feels like MVC, it's not MVC. All those great MVC features we all love, the Web API team decided to copy/re-implement, instead of building on top of MVC. Web API does not depend on MVC. It doesn't even depend on ASP.NET.

The best thing about MVC is it's extensibility. Now all those great MVC extensions will have to be recompiled/adapted for Web API. This is a terrible design choice, all they had to do was provide more RESTful features directly in MVC, instead of creating the Web API beast.

ASP.NET MVC Plugins

2012-02-14T01:12:00.000-03:00

There aren't many plugin solutions available for ASP.NET MVC, if you google asp.net mvc plugins you'll find many proof-of-concept on how to load views embedded as assembly resources, but few established projects. Loading embedded views is only one part of the puzzle, first we should focus on routing.

Routing

MvcContrib Portable Areas solution to routing for plugins is a very simple one: Plugin = Area. And it works. All you have to do is:

Add a reference to the portable area assembly (or copy to 'bin').
Call AreaRegistration.RegisterAllAreas() on Application_Start.

The problem with this solution is you are not in control of the URL space used by the plugin. For example, Portable Areas includes a sample called LoginPortableArea. All routes defined by this area start with Login/, and, apparently, you cannot change that (unless, of course, you recompile the plugin). What if you don't want to use Login/, but Account/ or User/ instead?. What if you can't use Login/, because it's already being used in your application?

With MvcCodeRouting you have complete control of the URL space used by the plugin. This is how you register a plugin:

void RegisterRoutes(RouteCollection routes) {
   
   routes.MapCodeRoutes(
      baseRoute: "Account",
      rootController: typeof(MvcAccount.AccountController),
      settings: new CodeRoutingSettings { 
         EnableEmbeddedViews = true
      }
   );
}

The baseRoute parameter specifies where you want to expose the plugin, it can be anything you want, even null, which means the plugin is exposed at the root of the application. The rootController parameter specifies the type of the controller that is the entry point for the plugin. MvcCodeRouting also create routes for other controllers in the same assembly. The settings parameter is used to customize the way routes are created, and to enable embedded views.

MvcCodeRouting is not a plugin-specific solution, you can use it to automatically create routes for your own controllers. In fact, the only plugin-related feature is views embedding.

Views

MvcCodeRouting uses a custom VirtualPathProvider to load embedded views. This is an optional feature, if you want you can just copy all views to your application. You can also override embedded views using file views in your application. How does it work? The VirtualPathProvider implementation presents a merged view (no pun intended) of file and embedded views. When a view exists in both file system and the assembly, the file view takes precedence. This is how you enable embedded views:

void RegisterViewEngines(ViewEngineCollection engines) {
   engines.EnableCodeRouting();
}

How to create a plugin using MvcCodeRouting

For MvcCodeRouting a plugin is an assembly with controllers, and optionally embedded views. That's all. In fact, if your plugin routes are simple enough ({controller}/{action} or {controller}/{action}/{id}) you don't even need to reference the MvcCodeRouting assembly. You can use hierarchical (a.k.a. RESTful) and custom routes by decorating your code with attributes.

View resources must be named using the following format: {assemblyName}.Views.{viewPath}. That means you just need to create a 'Views' folder in root of your plugin project and put the views there (and set Build Action to 'Embedded Resource', of course):

Conclusions

MvcCodeRouting makes it really easy to create and use plugins. The application developer (plugin user) is always in control of the URL space used by plugins, and can individually override views as needed. The plugin developer does not need to worry about how the plugin is exposed or how views are located.

Where to go next

mvccoderouting.codeplex.com
mvcaccount.codeplex.com

Hello World 2.0

2012-02-12T19:06:00.000-03:00

This is my second blog attempt. After falling in love with StackOverflow I decided I didn't need my (first) blog anymore, SO provided a much richer interaction. When I had a question I would just ask it on SO. If I had an answer, I would look for the question, if found and no answer looked like mine I would post my answer. A couple of times I post a question just to post my own answer, but that didn't feel right. With time SO got stricter on what kind of questions were allowed. Then came Programmers, but never really connected with it. I don't understand why that site, created for programming questions not suitable for SO, has so many closed questions. What's next? Programmers 2? I missed the freedom to just post anything I wanted, no rules, no scores, so here I am again. This time I'm much more skilled and experienced, so I hope to connect with a larger audience.