T4MVC 2.6: MVC 2 Areas support

To get the latest build of T4MVC:

Go to T4MVC page on CodePlex

One of MVC 2's major new features is the support for breaking up a large application into "Areas". This works by following a structure that looks like:

  • Root folder
    • Models
    • Views
    • Controllers
    • Areas
      • NerdDinner
        • Models
        • Views
        • Controllers
      • Blog
        • Models
        • Views
        • Controllers

So basically you still have your top level Models/Views/Controllers folders, and in addition to that you can have an arbitrary number of “Areas”, each having their own set of Models/Views/Controllers folders.

Starting with MVC 2.6, T4MVC lets you use areas in much the same way it lets you access top level items.  e.g. you can now write:

 <%= Html.ActionLink("Delete Dinner", MVC.NerdDinner.Dinners.Delete(Model.DinnerID))%>

Note how we referred to the controller as MVC.NerdDinner.Dinners.

Optionally, if you set IncludeAreasToken to true in the settings file, this becomes:

 <%= Html.ActionLink("Delete Dinner", MVC.Areas.NerdDinner.Dinners.Delete(Model.DinnerID))%>

Lots of headaches to find a good naming pattern for Areas in T4MVC

Surprisingly, one of the things that caused the most headaches in getting this working was finding a well working naming pattern.

Here are the patterns that were on the table:

  1. MVC.NerdDinner.Dinners
  2. MVC.NerdDinnerArea.Dinners
  3. MVC.Areas.NerdDinner.Dinners

#1 is the simplest and most concise, but breaks if you have a top level controller that has the same name as the area.

#2 appends ‘Area’ to the area name to solve the conflict we caused by #1.  But while it solves the conflict, you end up with a slightly quirky naming scheme.

#3 uses an extra Areas token before the area name to avoid the conflict.  The drawback here is that you end up with one more token, meaning one more thing to type through in intellisense.

I then polled twitter to see whether people preferred #2 or #3, and most went with the cleaner and more wordy #3.

Then Nikhil suggested using a hybrid of #1 and #2, where we only append ‘Area’ to the area name if we detect a conflict with a top level controller name.  Let’s call this #4!

So I ended up supporting both #3 and #4, based on the IncludeAreasToken switch in the settings file.

But frankly, I’m considering getting rid of #3.  In the twitter poll, people didn’t like #2 mostly because it’s weird to have that extra ‘Area’ suffix.  But with the hybrid #4 solution, this funky name only occurs exceptionally, making it much less of an issue.

To end this post, I’d like to thank Nathan Roe for helping out putting together this change!