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.

1. 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.

I was going to talk to some of my fellow developers about a couple of database issues.  The response was, “you said the ‘D’ word.  Now, we are an NHibernate/Microsoft SQL Server shop (or, Fluent NHibernate), and we rarely have to think about think about database architecture.  Heck, up till a month ago I don’t think we had to do any native SQL queries at all.  Currently, I don’t think we have any stored procs at all.  In my book, all of that is a good thing.  You can also chalk one up to Microsoft SQL Server in this one, our system has grown a lot and performance has remained pretty darn stable.

And lets be frank, I love this – most of the time.  Linq To NHibernate queries, Fluent NHibernate, and the like all make for a very enjoyable experience for developing against a database.  I would say that the vast majority of our querying needs are met with no further issues.  I certainly don’t want to go back to a stored proc world. 

That said, I don’t like using our ORM as an excuse to not talk about database issues or SQL issues.  If you are using a particular data storage technology, it still behooves you to know as much about it as possible.  Otherwise, when you get to a point where you need to know about what is going on will be too late.  Lets be frank here, no ORM will handle all of you query needs.  At best we are talking 90%, sometimes only 80%, for a typical application.  At some point you either have to go to the metal, or you end up coding things in a very strange way.

So here is the main point, as long as Relational Databases continue to be the “right answer” for business data storage, you need to learn database theory and SQL.  You might not need to know SQL as well as your native C#, Ruby, or other main language.  But that is not an excuse for not being comfortable with left outer joins, third normal form, and indexing.

Then the hands started raising.  Quickly, I might add.  I had to explain myself.  Yes, JavaScript goes at the bottom of your page.  Yes, I realize that we were all taught, back in the day, that JavaScript’s true home was in the <head> element.  In fact, many sample pages still show JavaScript at the top.  But we probably learned that ten years ago, you have to think a few things have changed…except IE6 – that sucker is going to live forever!  Anyway, I’m not the type that like to stand up in a crowd and say “everything you, and everyone you know, is doing is wrong” (I’m not that smart).  And if I do, I want to come with some substantial proof.

To start, where does the w3c say the SCRIPT element is supposed to go?  If you read the document in the link, SCRIPT can live in either the HEAD or the BODY elements. So technically, both places are legal.  I am stating this so that no one come back and tells me I’m breaking any fundamental web rules.  If the w3c says it is ok, then it is ok darn it.

But why the bottom of the page? 

That one is slightly harder to explain.  But here are the basics:  when a browser loads a document there are only so many thread for processing the document and download all the other crap that you put on the page so it pops (so, images and css, not to mention the bagillion font tags that Word likes to put in html).  There is also an unwritten rule that JavaScript should enhance the page after it is loaded.  So any time the browser spends parsing JavaScript is time it could be using to make the page look right.  Also, with some browsers, when the browser is loading JavaScript, ALL OTHER ACTIVITY STOPS.  Nothing else is downloaded, the browser is at a standstill until all the script is parsed – and you know how fast IE is at JavaScript.

Lets be clear about this “rule”.  I did not make this up.  But there are other ways around the performance penalty, you can also defer load your JavaScript.  Also, putting all of the JavaScript into a single, external file is a great idea.  With a external file you get the added benefit of the JavaScript file being cached by the browser (Note: great for the user – pain for your tester.  Repeat after me, “CLEAR YOUR CACHE” often when testing).

OK, so let us review.

But how bad is this?

That is a fair question as well.  Truthfully, it depends.  I know that is my stock answer, but I’m talking about how much this will affect the user.  It could be nothing.  But if you have a lot of JavaScript on the page, it could be significant.   Potentially it could be as annoying as a blink tag.  Even worse it might be on par with ESPN and their auto-playing videos.   But, if we are talking about 10-20 lines of script, there could be no change at all in render time. I will say this, by moving the script to the bottom of the page I have taken pages that were not usable for 10 seconds, improved it to moments (the page had a LOT of JavaScript…and it was a very noble cause).

What else should I be doing that I’m not?

This one is easy.  Run all of your pages through YSlow and PageSpeed (you need FireFox and Firebug installed for this) and find out.  Also, you don’t have to be perfect as far as these tools are concerned.  Some of the rule are probably not practical either (the “You should be using a CDN for images” rule comes to mind).  But it is good to know where you can improve.  PageSpeed has a number of really nice tools as well.  It will return you properly sized images, and compressed CSS and JavaScript if you ask it.

Here is the problem, as I see it:  as an MVC project gets large, keeping all of the necessary pieces and parts for a set of controller actions straight can get a bit daunting.  I’ve ended up with duplicate folder structures in views and models, which can make navigation a pain.

To make a new Area, simply right-click anywhere in you MVC project, Add->Area.  As I said, you can do this from anywhere in the project structure, but the Areas are created in a new “Areas” folder.  When you name the Area, a new folder is created with the Areas name as well.

Once created you should see all the familiar Controllers, Models, and Views folders (all blank).  In addition to that, you will see an <name>AreaRegistration.cs file.  This inherits from AreaRegistration, and this is where any new Routes go.  In the file is a prebuilt route that should look similar to this:

   1: context.MapRoute(

   2:     "test1_default",

   3:     "test1/{controller}/{action}/{id}",

   4:     new { action = "Index", id = UrlParameter.Optional }

   5: );

So a url to the area would include /test1/ (name of my Area) in the path.  That would be good if you had multiple controllers with the same name, but if you don’t, just take out the “test1” and you won’t need it in the path.

Also, if you leave Area name in the route, you will have a little more work to, here is what one of mine looked like:  <%=Html.ActionLink("test", "Index", "test1/TestArea") %>.  But it turns out this is more correct:

<%=Html.ActionLink("test", "Index", "TestArea", new { area="Test1"}, new {}) %>

This also mean that any controller actions you want to link to outside if Area needs to include a blank area in the link, like this:

<%=Html.ActionLink("Home", "Index", "Home", new { area=""}, new {}) %>

In case you are wondering, the first object in the area is for route values, the second is for html attributes.

So the downside of using Areas is that you could complicate your routing in a hurry.  Plus it does not look like the Html helpers are there to lend you a hand either.  It is very doable, just annoying.  Of course, the easy fix is to remove the Area name from the route and move on.  That should be ok so long as you do not have two controllers with the same name.

So are Areas a compelling feature? I think so.  Plus, the larger the site, the more compelling Areas can become.  For smaller sites, probably not.  But I would not say no either.

My first thought was “Crap, this is going to be rough”.  Mainly I was still thinking of my time trying to test Code Behind in Asp.Net WebForms.  I had to smack myself a few times after I remembered that the Controller base class is an abstract type.  Reality is that a Controller doesn’t have to be any harder to test than any other service class.  It isn’t like inheriting from Page (Asp.Net WebForms).

Not that my code did not have some lingering issues.  Like: why did I have something in my Controller Action that would require testing in the first place?  I hate having much logic at all in my Actions.  Get input, send it off for processing (logic), go somewhere.   That should be about it – unless you have to go to different places depending on what is returned.  Now, I want some tests.

Anyway, now back to your regularly scheduled program.

Lets start things out by outlining the various parts of a web page:

• Title
• Header
• Content
• Footer
• CSS includes
• Script includes
• JavaScript

Typically, without eliciting some tricks, there will be some JavaScript in your page, as there will be some part of the script that is dynamic.  But best case, all of the JavaScript that you need can be put into a separate file.  But even then, if we are talking 5 lines of JavaScript I will probably give you a pass if you keep it in the file.

But what I want to do is encourage best better practices.  CSS is declared at the top, JavaScript at the bottom, html in the middle, code you want to run right after the page loads here.

So here is a typical MasterPage after I’ve made a few modifications:

   1: <%@ Master Language="C#" Inherits="System.Web.Mvc.ViewMasterPage" %>

   2:  

   3: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

   4:  

   5: <html xmlns="http://www.w3.org/1999/xhtml" >

   6: <head runat="server">

   7:     <title><asp:ContentPlaceHolder ID="TitleContent" runat="server" /></title>

   8: </head>

   9: <body>

  10:         <asp:ContentPlaceHolder ID="MainContent" runat="server">

  11:         

  12:         </asp:ContentPlaceHolder>

  13:  

  14:     <%
   1: = Html.IncludeScript("~/Scripts/jquery-1.3.2.min.js") 
%>

  15:     <asp:ContentPlaceHolder ID="ScriptIncludesContent" runat="server">

  16:     

  17:     </asp:ContentPlaceHolder>

  18:  

  19:     <script type="text/javascript">
   1:  

   2:     $(document).ready(MasterLoadPage);

   3:     

   4:     function MasterLoadPage(){

   5:         <asp:ContentPlaceHolder ID="DocumentReadyContent" runat="server">

   6:         

   7:         </asp:ContentPlaceHolder>

   8:     }

   9:     

  10:     
</script>

  20: </body>

  21: </html>

You can see that I’ve added some extra placeholders in the code there. 

But does any of this suck? Yes.  When you add a page that implements this master page, you will get all of the appropriate content areas, but they will all assume that you are going to add html/text to them.    The consequence is that the DocumentReadyContent Content area that is generated cannot help you with any JavaScript/Css intellesense. 

To some extent, that is still ok, as I am looking to minimize the amount of JavaScript and css in my pages…you could say the pain is disserved.    But what would be nice is if we could add a language indicator to the Content element. (hint: Microsoft VS team, I’m looking at you).  

If you also think adding language indicators would be cool, vote here: http://aspnet.uservoice.com/forums/41199-general/suggestions/487773-make-language-specific-contentplaceholders-

Happy hacking.

So being a Microsoft kind of guy, the move to Windows 7 Media Center was an easy one.  The hard part was assembling the hardware was all I needed.  Plus being overly Dutch (I’m first generation American, but still) I really wanted to do it on the cheap.  That means cheaper than a comparable Tivo with a year of subscription costs.

I should also note here: I do not subscribe to cable, satellite TV, or even Netflix.  I don’t like monthly fees.  All I have is an antenna, which gives ms about 20 channels (four of which are PBS, which is fine by me).  So even though I get a lot fewer channels, I still like to record programs, sometimes two programs at the same time (double header football games on Fox and CBS).

My Hardware:

The PC: I got a Dell Zino HD (Inspiron 400).  You can get this machine for as little as $250, but after upgrades I ended up spending $400 ($40 was shipping).  I upgraded to a dual-core CPU, got the wireless package, and got the blue cover.  One thing I should have done was upgrade the hard drive.  The default is 250 GB, you can go up to 1 TB.  I’m going to make up the difference with an external hard drive.  I also have a few other computers with a bit over a TB of storage on the network.  Also, I plan on using the HDMI connection to connect to my TV (flat screen) for both picture and sound.

Signal Converter: SiliconDust HDHomeRun 250 ($130). one thing the Zino does not do is take an antenna signal.  This is a dual signal tuner which is exactly what I was looking for.  So the HDHomeRun converts the signal and exports it to your network.   The box also comes with software to install on your computer(s) that will connect your pc and Media Center to the HDHomeRun.  Downside of this approach was that now I needed a small router next to my TV (I don’t have a Cat5 line to my TV).  That wasn’t a big issue for me, I have a spare router.

Remote: Vista MCE Remote Control (VRC-1100). ($22).  Let me say, this was a mistake on my part.  The remote works, but this one kind of stinks.  There is a big round button in the middle that acts as a mouse – which is OK.  But the controls on the top half are all badly positioned.  I like a remote you don’t have to look at to use, this one fails that test.  Buy a better remote than I did.

Done.  Actually, that is all you need.  I spent about $550.  A comparable TiVo would cost $408 plus about a $13 monthly fee, that would run $560 for the first year.  So I don’t feel too bad about how I did.  But do note, this is a basic system.

How does Media Center compare to Tivo (software-y-softare   **cough** mono-y-mono)

I’m comparing Media Center to TiVo Version 2 here.  I don’t have the latest version.

• I get 2 weeks of programming with Media Center – 3 days with Tivo (I don’t subscribe).
• TiVo has a way to skip ahead 15 minutes.  I miss that with Media Center.
• Media Center still plays sound when fast forwarding.  I love that feature.
• Media Center can skip ahead 15 seconds.  Also a great feature.
• Lots of Plug-ins for Media Center.  Lots.  TiVo…not so much. (that I know of)
• Media Center is still Win7, I know what I can do with that.  TiVo is a bit more closed minded.
• I can view the channel guide and still watch the current program with Media Center.  Then view a single channel, and sort by time or name.  Beautiful.
• With home network, I can view all of my family pictures stored on other computers.  Same with videos.

Verdict: I’m happy with Media Center.

What is next? Lets start with what I’m missing. 

1.  Surround sound is one.  I need to figure that part out.   But for now I’m keeping my old DVD player and receiver handy (I also have an old receiver that does not take HDMI).  But this system is perfectly fine for all of my kids movies (they don’t like the subwoofer anyway).  But I’d like to find some USB-type surround sound device.

2. BlueRay.  I did not get a BlueRay player…actually, I don’t care about that.  I see BlueRay on the huge displays at stores, I just don’t see enough of difference to care.

3. Xbox 360 Controller.  I also want this box to be a gaming machine.  The more uses I can get of the machine the better.  I’m not serious enough to get really crazy, but a few games here and there would be nice.

4. WebCam?  I have a thought of installing Skype and turning it into a phone as well.  But maybe not.

So, in conclusions, I’ve happy with the Media Center system I was able to put together.  It does what I want, it is extensible, and there are plug-ins to do almost anything else I want (local weather).

And if you have ever worked on web applications you should be familiar with the “user went to lunch” issue (session timeout).  User leaves for an hour, comes back to your web page, and expects it to continue working.  Unfortunately the session timed out, and now you have to refresh a bunch o’ crap.   Another version of the problem, the “.ASPXFORMSAUTH” cookies gets deleted.  Either way, your web site stop just working and the user blames you.

The fix is to have the user log in again.  Normally this is simple, when the user does something, then the page is refreshed and redirected to the login page (as assigned in the web.config).  That is the standard web model.  Unfortunately it does not work in this case.

Web services complicate things.  When inside a web method request, redirects do not work, and even worse if you are using JQuery “load” method (which loads html directly into an element), then you get the login page inside of a div.  But more often, your web client code is expecting JSON, and will be getting html (an error page or the login page).

So my current solution it to wrap up the JQuery AJAX methods with my own methods.  This way I can check the users authentication (another web method).  If I see the user is not logged in, I redirect to the login page.  The other web method is killed via the page redirect.

Here is my wrapper:

   1: var ajax = {

   2:     _lastAuthCheck: new Date().getTime(),

   3:     getJSON: function(url, data, callback) {

   4:         ajax.CheckAuthentication();

   5:         return $.getJSON(url, data, callback);

   6:     },

   7:     post: function(url, data, callback, type) {

   8:         ajax.CheckAuthentication();

   9:         return $.post(url, data, callback, type);

  10:     },

  11:     load: function(destination, url, params, callback) {

  12:         ajax.CheckAuthentication();

  13:         destination.load(url, params, callback);

  14:     },

  15:     CheckAuthentication: function() {

  16:         if (!TimeToCheckAuth()) return;

  17:         $.getJSON('<%=Url.Action("IsAuthenticated", "Account")%>', null, function(result) {

  18:             if (!result) {

  19:                 window.location = '<%=Url.Action("LogOn", "Account")%>';

  20:             } else {

  21:                 ajax._lastAuthCheck = new Date().getTime();

  22:             }

  23:         });

  24:         

  25:         function TimeToCheckAuth(){

  26:             var currentTime = new Date().getTime();

  27:             var diff = currentTime - ajax._lastAuthCheck;

  28:  

  29:             return (diff > 5000);

  30:         }

  31:     }

  32: };

Now with the wrapper in place I switch my $.ajax, $.get, $.post calls to ajax.ajax, ajax.get, ajax.post.  All the parameters should stay the  same.

Notice one thing, I’m mixing in Url.Action calls in that code.  I should add that this code is in a separate file for me, not in my web form page.  If you want to get more of an idea of how I do that, check out my post on Asp.Net MVC JavaScriptView.

Now the web method, IsAuthenticated, is about as simple as you can get:

   1: [AcceptGet]

   2: public JsonResult IsAuthenticated()

   3: {

   4:     return Json(User.Identity.IsAuthenticated);

   5: }

But back to the JavaScript, there are a couple of other things going on here.  First off, the authentication check will happen at the same time actual web method call.  I banking on the theory that the authentication check will return before the other method.   Second, I put an extra check in the method, so at most the authentication check will only happen once ever 5 seconds.  Adjust as you feel necessary.

OK, if you have a form where the inputs of the for have both id and name  attributes, the name attributes trump id.

So if you have this:

   1: <input type='type' id='RegisterUserName' name='userName' />

Then you write the validation against ‘user’Name’, not ‘RegisterUserName’.

   1: $("RegisterForm").validate({

   2:     rules: { userName: {required: true} }

   3: });

If you do not you will get all sorts of strange null exception errors (which in JavaScript means something returned as ‘undefined’.

How this happens

People have been talking about the great flexibility of Asp.Net MVC for a while now, but there are a few things to be aware of.  One of them is multiple forms. 

Say you have a web page that has two forms on it, one to register users, the other to log users in.   Both forms have ‘username’ and ‘password’ fields.   Asp.Net MVC still cannot get you around the need to keep ids unique – but names can be reused.   These names are also read by Asp.Net Action Controllers.  So if you have multiple forms all submitting to the same Controller Action, as long as the name attributes are set it will hook up.

Anyway, this is a short post, mostly for myself, so I don’t spend two hours figuring this out again.