First time here? You are looking at the most recent posts. You may also want to check out older archives or the tag cloud. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS. Thank you for visiting! (hide this)

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.

Shout it kick it on DotNetKicks.com

posted on Thursday, October 15, 2009 12:54 PM

Comments on this entry:

# re: My ASP.NET MVC stack and why I chose it

Left by Elijah Manor at 10/15/2009 4:29 PM

Have you used Spark with ASP.NET MVC v2 Preview 1 or 2? I was wondering if the new Templated Helpers work well w/ Spark.

# re: My ASP.NET MVC stack and why I chose it

Left by Simone at 10/15/2009 4:38 PM

Not tried this combination yet. Sorry.

# re: My ASP.NET MVC stack and why I chose it

Left by Elijah Manor at 10/15/2009 4:44 PM

Well, then I might be navigating uncharted waters ;) I've played some w/ Spark and would really like to use it in my current project, but not at the expense of the Templated Helpers. Thanks for the quick response!

# re: My ASP.NET MVC stack and why I chose it

Left by runxc1 at 10/15/2009 4:44 PM

So tell me what do you plan on using for reporting or do you not need a reporting tool? I am talking about a Crystal Reports alternative or something and not just a graph on a page.

# re: My ASP.NET MVC stack and why I chose it

Left by Simone at 10/15/2009 5:05 PM

@Elijah: Not that you are navigating uncharted waters, it's just me that have not as much time as I'd like to test new things :)

@runxc1: They already have a reporting service in place to do the analysis of historical data. The monitor I'm building is just the real-time monitoring.

# re: My ASP.NET MVC stack and why I chosen it

Left by Shuaib Rameh at 10/15/2009 5:34 PM

Grat post man. I wish you best of luck man. I have worked with jr. developers and it is not easy to tell you.
Looking forward to see the end result post.

# re: My ASP.NET MVC stack and why I chose it

Left by David Hayden at 10/15/2009 5:48 PM

Sounds like a good stack to me. I am always using Enterprise Library, Unity, LINQ To SQL, and Webforms View Engine for my clients who prefer the Microsoft technologies. Plenty of developers who can develop and support that stack.

At the same time you gotta love the ELMAH, Ninject 2, LightSpeed / NHibernate, and Spark View Engine stack which feels oh so nice :)

# re: My ASP.NET MVC stack and why I chose it

Left by Simone at 10/15/2009 5:57 PM

My choice was somewhat mixed between the pure MS stack that is probably more standard among the majority of developers and the stack that I prefer, which is the one I consider the best possible one.
At the end I decided for the mixed one, with some libraries from the standard stack and some from the ALT.NET stack.

# re: My ASP.NET MVC stack and why I chose it

Left by Danny at 10/16/2009 5:42 AM

Simo,

Agreed , once you've seen and worked with MVC it's very difficult to go back to
webforms. I'm sure you'll be a great mentor.

On day one everybody gets one of your tee-shirts - remember from
last summer.

Best of Luck.

# re: My ASP.NET MVC stack and why I chose it

Left by Nilesh Gule at 10/16/2009 7:56 AM

I am also working on a project on ASp.NET MVC with almost a similar stack. Except for the ViewEngine and Source control and CI integration rest of the things look similar. All the best for your project.

# re: My ASP.NET MVC stack and why I chose it

Left by Maarten Balliauw at 10/16/2009 1:54 PM

I'm working on a reference architecture on ASP.NET MVC, and have almost the same stack. Spark is one of the choices I also did because it forces you even more to think differently than with webforms. Using AutoMapper and view models separated from domain model is also best practise.

I'm really curious how your project works out, keep us informed!

# re: My ASP.NET MVC stack and why I chose it

Left by Simone at 10/16/2009 2:46 PM

I think that this, with a few changes, is the most used stack for ASP.NET MVC applications... maybe using NHibernate instead of a Linq2Sql and using some other IoC instead of Unity.

I'll keep you posted, mainly about how the team "reacts".

# re: My ASP.NET MVC stack and why I chose it

Left by John at 10/16/2009 2:53 PM

Interesting post. Why did you choose jqGrid over say, the one from MVCContrib?

# re: My ASP.NET MVC stack and why I chose it

Left by Abe Park at 10/16/2009 7:55 PM

By the way, what would be your best possible stack, if you had full control of a project?

I'm still have a lot to learn, but I've had so much fun learning and working with the following:

ASP.NET MVC
Spark View Engine
Linq to Entities (well, not that fun)
Subversion
Elmah
YUI 2
CruiseControl.Net (for CI)

Can you give more explain more about the Enterprise Library, Automapper, or I give an overview of the programming practice behind those tools?

Thanks!
Abe

# re: My ASP.NET MVC stack and why I chose it

Left by Simone at 10/16/2009 9:40 PM

My best possible stack would be the same as above with a few changes:

NHibernate + FluentNH instead of Linq2Sql
Elmah and FluentValidation instead of EntLib
Ninject instead of Unity
and probably now ASP.NET MVC v2 even if still in beta

# re: My ASP.NET MVC stack and why I chose it

Left by Fatih Sever at 10/18/2009 10:56 PM

We've started new project too and have almost the same stack. We've chosen Entity Framework as repository and also we're using Velocity Distributed Cache for data caching. There is a useful caching and tracking wrapper for Entity Framework called EFProviderWrappers, you know. We've chosen jQuery UI too but we're planning to switch Telerik Extensions for ASP.NET MVC. It looks like cool.

Thanks for your great post. It's good to see what other projects choose.

# re: My ASP.NET MVC stack and why I chose it

Left by Rohit at 10/19/2009 10:06 AM

I see that you prefer NHibernate over Linq2Sql.
I'm in a dilemma of choosing an ORM technology and just can't decide which one to opt for. Both of them seem equally good. I am looking out for a pressing reason for choosing NHibernate.

Thanks for the excellent post.

# re: My ASP.NET MVC stack and why I chose it

Left by Simone at 10/19/2009 10:40 AM

@Fatih: Good plan as well: I'd have loved to use Velocity, but no need for it at the moment.
And with EF, since v4 is not out yet, and the datamapping just a few and various, we decided to go with plain data access.

@Rohit: Linq2Sql is just a querying tool, not a real ORM as NHibernate is. I'd compare Enity Framework v4 with NHibernate.
At the moment I'd choose NH over EFv4 because EF4 is not release yet, and I didn't have the chance to play with it yet. EFv1 is not an option as, IMHO, it should have never been released since it lacks the basic features of an ORM.

# re: My ASP.NET MVC stack and why I chose it

Left by Louis DeJardin at 10/26/2009 8:50 PM

Probably a good call avoiding an ORM on top of a legacy schema, especially if the team is new to the concept. Retrofitting can such an awkward fitting process, and the benefits are limited by existing db design, it's a really hard decision to defend compared to direct query behind a data access layer. Especially if the data access layer acts as a record-model-mapper that hides db details.

Even with a system that's ORM enabled I've always considered ADO a tactical option where legacy data is concerned.

Comments have been closed on this topic.