I've been working with a team of guys on several Asp.Net MVC projects since October of 2009. While that isn't the greatest amount of time, and I'm still no expert, I thought I'd jot down a few of the practices that we have developed to help make coding a bit smoother. Asp.Net MVC, as with every new technology can be used poorly, and when use poorly you try to identify why that code was bad, how it could have been done better.
First, lets think about what the view should be doing - in a single responsibility sort of way: turn data into html. That right there rules out several options. No retrieving data, no extra data transformations. Just turn some data into html. And frankly, that is complicated enough. So a side goal that I strive for is to create a markup page (the aspx) that is similar to the desired html output. The main reason for that side goal is to make double checking the output that much easier. I want to see a 'div' in my markup, and have a reasonable idea where that 'div' will show up in the html.
- Keep as much code out of your views as you can.
Don't make this rule overly simplistic. Some code belongs in the view. A 'for' loop to create a table, a simple 'if' block to show administrator functionality, stuff like that. But you shouldn't be having to specify the DateTime format, or string parsing. That is what the ViewModels should do for you. Rule of thumb, if you see a block where there is more C# than HTML, you probably did it wrong.
I will also extend this rule to JavaScript as well. I've talked about the why JavaScript should not be in the views before, so this should not be a shock. JavaScript belong in separate files. Period.
2.
Make Views typed.
This is true for all views where you have to pass data from the controller to the view. Make a View Model for the view and pass data via that model. This opens up a whole host of better patterns for you, like typed HtmlHelpers. As a result, it is VERY rare that I will share a view model between views, or even Controller Actions. I make separate models for GET, POST, and DELETE. I guess my view is, the more the merrier.
3.
Make the View Models specific to the needs of the view.
OK, this isn't actually a View best practice, but it is highly related. If you try to keep the model for the view too generic, you end up with a lot of logic in the view to transpose the data into something useful. The key point is that the data in the model serves the view, so all of the work to get the data into the correct format should be done when putting the data into the model. I will often take this to the point where the model will give html elements in the view their CSS classes. So that means I have more than data from the database in the views.
Side note: when it comes to populating View Models with data specific for the View,
AutoMapper rocks! That is all.
4.
Custom Html Helpers are wonderful things
It is remarkably simple to create your own Html Helper, and once you get the hang of them they are beautiful. They are wonderful little ways to encapsulate a small amount of logic so you can get it out of the aspx view. Use them to encapsulate small amounts of code you need in various place through the project.
Another little "trick" I will use from time to time to create custom models just for a html helper (passed in via the view's view model). I have a few places where I need to change the markup because of the browser being used...so I create a custom helper that can detect the browser.
5.
Standard HTML Helpers are great, but remember html
The key point I'm trying to make here is to become familiar with the output of the standard HTML helpers. While the helpers can be great, they have their warts (anything having to do with an attribute name/value is a bit ugly). Sometimes it is easier to swap them out with the standard html (especially with inputs) to get the exact output you want. As a bonus, it is easier for the next guy coming in to figure out what you were after. Currently, I'd say I use the helpers about 50% of the time over raw HTML.
Now, typing the html, or the helper, still kind of stinks. You have to type the same code over and over. Take a look at what
Zen-Coding does. You can do the same thing with ReSharper Templates or Visual Studio snippets...or just install one of the ReSharper or Visual Studio pluggins. But beyond that, there is an art to customizing Visual Studio that you should learn.
6.
Wrap all links in Url.Content and Url.Action
You have a web app. You have to navigate between pages, call web services, link in javascript and CSS. That is just what we do. All of those links should be wrapped in Url.Content or Url.Action helpers. The problem that is easy to run into is you move from development to test and the base url for your application changes. You were testing at http://localhost:898989/ , and now you are deployed to http://myserver/myapp/ and a whole lot of urls just stopped working. Url.Content and Url.Action are supposed to fix that. That is why you use them.
7.
Get to know Partial Views for Ajax calls.
Partial views are actually just views that don't have master pages and the html/body tag sections. Partials can be executed in a multitude of ways, not just from inside a view on the server, but also from Javascript on the browser. JQuery also has a wonderful little method called $.load that will call a url, take the html that is returned, and slap it into the page. This can greatly simplify a lot of behaviors.
I subtle little trick I sometimes do with this this is to wrap a section of code that takes a long time to load in a partial. I will then call that partial into my page AFTER is has loaded on the browser (using the JavaScript function setTimeout to call the $.load ). Now I get a page that loads faster, but still has all of the data it needs.
8.
Make the Master page work for you.
It isn't that there is something inherently wrong with the existing master page that you get when you create a new Asp.net MVC project. Typically it is 80% of what you would want. But, as soon as I know what my general page is supposed to look like, I rip right into the Master Page. Also keep in mind that you can nest Master Pages as well.
9.
Think about what a designer would want.
Even if you don't have one. This is just a general pattern I try to get into. I think about a designer as someone that can take raw html, add some css and images and make my work look a LOT better. This means I use the raw html whenever possible, I write my JavaScript click handler so they will work with buttons or links (hint: always return false -- and why haven't I written a JQuery plugin for this yet?).
10.
Version your css and JavaScript
This is actually getting into my next blog post, but figure out a way to version your JavaScript and CSS. This really isn't MVC specific, you should do this in almost any project. The key reason is to help you with a browser's cache. You know you have a problem when the first thing someone tells you, when asking for help, is that they cleared their cache already. My thought on this is your web app's dll should have a version number, set the project to auto version, and then pop that onto the end of the css/javascript file call. So it might look like this: "http://myapp/.../file.css?version=1.0.0.256". In my sample code, when in development I stick a timestamp on the file in the same way.
OK, 10 rules is quite enough (I didn't even think I would get that many). To the american's reading this: Happy Independence Day.
Chris Brandsma
