My ASP.NET MVC Stack and Why I've Chosen It

In my current project I'm starting to develop a new web application using ASP.NET MVC and given all the environmental conditions, choosing the stack, from the tools to the libraries was not an easy task. I had to come to a few compromise to cope with all the different "forces" involved, so I though it would have been a good idea to share my reasoning and the final decision to show an example how an architect that works in "normal" company (as opposed to HeadSpring and such kind of on-the-edge companies) has to balance between what is the best possible option (but sometimes not feasible) and what is the option that is good enough but feasible.

The facts

In order to understand the decision is important to understand what the application is and how (and by who) it is going to be developed.
Without going into the details, the application is mainly a dashboard that manages and monitors the performances and health of an application server. What it will do is retrieve data from the main application server (either via reading the "main" DB or by calling some web service), visualize them in an easy to read and understand manner, and do some quick maintenance and management of the system like restarting, stopping and changing some of the configuration parameter.
Another important fact is the team that will be developing the application: it will be me and a few junior developers with a 1-2 years of experience of developing in .NET and very little (if not nil) in developing web applications.
And finally, the main application is a mix of Java, .NET and COBOL and the team already has source control and a kind of build server that performs nightly builds and deploys to a test environment.

The stack

Now that I made the environment clear, let's review the stack and why I choose each piece of it. Starting from the tools.

Tools

Visual Studio 2008 + Resharper

That was kind of an obvious choice: we are building the software with ASP.NET MVC, the .NET 3.5 and I'll try to introduce the team to a more agile way of developing software, so ReSharper, with all the refactoring tools, will make the life easier.

SubVersion

As I said, the IT of the client already has a source control system in place, and it is Subversion, so we'll go with it.

Maven/Hudson

The client's team is mainly a Java oriented team, so they setup all the build server using java tools: they used Maven to build the projects and used Hudson to schedule the builds. I always used NAnt, MsBuild, TFS and CC.NET but since they already had all this place, I had to go with that. But it turned out to be a good thing: it seems like Hudson is probably the best CI server out there at the moment, and also has a lot of .NET related plugins. So this is turning out to be an opportunity to learn a new thing.

The libraries

Let's see something probably more interesting: the libraries used.

ASP.NET MVC 1.0

I don't think I'll ever go back to starting a new web project using Webforms (unless forced to). But even without my love for the framework I probably would have chosen ASP.NET MVC anyway. A dashboard is the kind of application ASP.NET MVC shines in: very little editing of data, and a lot of data rendering, visualization and ajax things. For that reasons I decided to stay with the released version 1.0 instead of going with v2 Preview 2: I don't have many pages and I don't need to separated the controllers and views into areas, and I don't have so many editing forms to need the Templated Helpers and the integrated ModelValidation.

Custom Data Repository with Linq2Sql

As said, there is not a lot of editing to do. Furthermore the dashboard is going to connect to a legacy database, designed in a really (and I mean really really) strange way, and unfortunately I've no jurisdiction over it. So custom repository with manual mapping is the way I decided to go. Furthermore the developers in the team are not familiar with an ORM. Actually they are not familiar with IoC, MVC, HTML+Javascript and writing tests neither. I didn't want to flood them with all that many technologies and practices all together. So I thought that ORM was the one I could skip for that project.

Enterprise Library and Unity

I always used Ninject for IoC, and Elmah for the logging, but Avanade is the company that wrote the first version of the Enterprise Library and it's part of the internal development framework. But after all the EnterpriseLibrary is not that bad, and this way I have the chance to play around with Unity and maybe find a way to study the validation application block in order to make a client side validation provider on top of it.

AutoMapper

Even if we won't have a lot of entities to deal with, AutoMapper will save us from writing boring mapping code. And will help the team to understand better the importance of having a model specific to each view and to keep the domain model separated by the view model.

Spark

WebForm View Engine holds too many connections with the WebForm's world so I don't like using it. Furthermore the developers of the team are not familiar with ASP.NET and very little with HTML/CSS, so I thought that Spark is a better solution since it is pure HTML with little customization compared to WebForm. And finally it will prevent developers from breaking the pattern including server controls with data logic in them.

jQuery

There was a bit of talking about whether using ASP.NET Ajax or jQuery, but at the end we opted for the latter. The reasons for this decision are various: we are using Spark instead of the WebForms ViewEngine, jQuery has a much bigger "add-on" ecosystem and in particular it has the jqGrid which by itself justifies the adoption of jQuery, and then the guys of the team heard about it and wanted to learn more about it.

jQuery UI

Tabs, datatime pickers, modal dialogs are all part of the Ajax Control Toolkit, but what the jQuery UI has is the unified theme: with just one line of configuration all your UI controls will look the same. And since we choose for jQuery, the ACT has never really been an option.

jqGrid

We have to implement a few grids that need to support sorting and paging: I already used this plugin before, and it's both easy to setup and very powerful. You can browse some samples and the documentation here.

xVal

We won't have many complex editing screens, just a one or two, but xVal is really easy to implement and I think it's worth adding it even if there is just one field to validate.

Testing

We are not going to do TDD (or maybe we will, let's see how the team goes first) but for sure we will write unit tests and we'll try to test the most important features.

MsTest

Even if I prefer mbUnit, the rest of the solutions is already using MsTest so, even if it's not my preferred testing framework, we'll go with that.

RhinoMocks

Fortunately the other tests are already using this great mocking framework, which is also the one I used the most and that I prefer, so all good on this side.

The result

Even with some restrictions, I think we ended with an application stack that is pretty close to what I'd have considered the best possible. Now the fun begins, and we'll see if the team will find MVC, jQuery and Spark easy to learn and to use. I'll keep you posted, and when the project ends I'll write a post sharing what was the experience of the team with the new stack and which problem we encountered.