Playing around with ASP.NET MVC

As I'm a big fan of Castle Project's MonoRail, I often get asked my opinion of the ASP.NET MVC stuff Microsoft is working on.  And I always have the same answer -- I've seen some demos but haven't actually played around with it.  So I took some time tonight and installed it.

Installation

You can download the ASP.NET MVC Preview 5 release here.  Double-click on the MSI and you get the usual welcome screen.

As always, there's a EULA to accept.

After that, you're ready to install.

And then you're done!  Painless and easy.

My First Project

After installation completed, I started up Visual Studio 2008.  At this point, the GhostDoc configuration screen appeared.  I had to repeat my GhostDoc set up.  That was weird!  Don't know if that had anything to do with the ASP.NET MVC install, but I hadn't done anything else with my VS2008 installation recently.

You'll now have a new Web project type called "ASP.NET MVC Web Application".

After selecting this I was asked if I wanted to add a unit test project as well.  Very nice!  Obviously, I selected "Yes".  :)

My solution was now all set up and ready to go:

Notice the project is pre-populated with folders for my controllers, models and views.  The web.config is also fully configured.  At this point, I clicked "Run" to see what would happen.

By default, the web.config is not set up for debugging.  I took the default and let VS.NET set up my config for debugging.

And now my first ASP.NET MVC project was up and running!

Comparison to MonoRail

Now I started poking around the directory structure.  I noticed that instead of a "layouts" folder they place their master pages ("layouts" in MonoRail) inside a "shared" folder.  Sounds similar to MonoRail's shared views.

I noticed that the view pages are still ASPX pages and contain a code-behind file.  This seems kind of odd to me as I'm accustomed to MonoRail's view files (mostly NVelocity) -- a single file that contains everything needed to render the view; no more, no less.  I could see that without discipline, the code-behind files could be bloated with business logic when it should only contain view logic.  Be careful!

Poking around the pre-built pages I noticed most of the "ViewData" (PropertyBag for you MonoRail people) output was wrapped in Html.Encode.  It would seem to me that you'd want to, by default, always HTML encode your output (like MonoRail does).  I think raw output of view data is the exception rather than the rule.  Others think it should be this way too.  Again, be careful!

Adding a New View

So it's time to start adding a little bit of my own code to this sample app.  I started with adding a new view.  When you do this, make sure you add a new "MVC View Page" and not the usual "Web Form":

The page popped up and I noticed something right away: There's no way to pick your master page when creating a new MVC View Page.  I'm sure this is just one of those things that don't exist yet.  I know that this selection step is available for web forms so it's probably just a matter of time before the ASP.NET MVC stuff supports this.

But, since it doesn't, you'll need to add the MasterPageFile attribute yourself as well as any ContentPlaceholder tags.  I grabbed them from one of the sample pages.

So now I just dumped some code real quick into the view.  As I typed, I noticed the Visual Studio was complaining about what I was typing:

It didn't like my "Html.Encode" nor my "ViewData" references.  I copied these right from another page?!  What was I missing?  An import perhaps?  Nope, the imports on the sample pages are the same as mine.  Then it hit me -- these view pages (like web forms pages) inherit from a base class.  That base class probably exposes the Html and ViewData objects.  Since I just created this page (and haven't compiled), the intellisense wasn't picking up the proper settings.  So even though I had the red squiggle's, I hit the build button.  Everything built fine and my page errors went away.

I put a line of code in one of the controllers to stick my name in the ViewData.  Then I added my new page (action) to the menu:

I ran the project and clicked on my link:

Ok -- I admit it.  Not too exciting!  And it barely scratches the surface of what you can do with ASP.NET MVC.  But I think I've showed it's pretty easy to install it and start using it right away -- even if you're not familiar with the MVC pattern.

I'll continue to use MonoRail for my web projects as it's more mature than the ASP.NET MVC stuff.  But I'll definitely be coming back to this stuff from time to time and playing around with it.  I think Microsoft has made the right decision in creating a whole new architecture for implementation of the MVC pattern and not trying to jam it into the Web Forms engine.  That would have been a huge mistake!