The ASP.Net MVC framework is what got me into web development. The MVC model made things click in my mind about how a website worked and how all of the parts fit together.

My prior brush with web development was using ASP.Net Webforms, an encounter that would soil my interest in web development for about two years, until I read about MVC.

See Webforms is pretty bawdy and the things you learn there don't translate well to other languages and frameworks. You drag components on the designer, write up some awful looking repeaters, etc. Recently it seems that many of the cool features that are in MVC are being translated over to the Webforms realm, in one way or another.

But I'm here to tell you to not use Webforms if you can help it, and use MVC. And here's how I typically structure my MVC3 web applications.

Keep in mind:

1. I heavily use Entity Framework 4 and Linq for data querying. My websites do not serve 1,000,000 unique visitors a day - I do not need the raw performance something like Dapper would provide. However, since this is using the Repository pattern there's no reason you can't just switch out Entity Framework with your ORM of choice.

---

Hello Project

First, I create an empty Visual Studio 2010 solution.

Then, I add the following three projects.

1. XXX.Tests (Class Library project) - For my unit tests.
2. XXX.Domain (Class Library project) - For my data layer.
3. XXX.WebUI (ASP.Net MVC3 project) - For my website. Don't forget to set this as your Startup Project.

---

Structure in the MVC3 project.

The default file structure is good enough and works, but I've come to like this structure I original saw used by Rob Conery in his Tekpub series for MVC2.

First delete the Content folder and everything in it. You don't need anything in there.

Next, create a folder called Public and inside that folder a folder called assets. Within that folder you'll create three folders, images, stylesheets and javascripts.

Finally, move everything in the Scripts folder into the Public/assets/javascripts folder.

You end up with a very clean, elegant structure that is dead simple to deploy when published. Basically, every resource a user can access should be in the Public folder.

---

Adding the Nugets (ie "magic")

I use Nuget to download third party libraries for my applications and here's what I download for each project in my MVC3 solutions.

XXX.Tests

I download XUnit via Nuget to run my unit tests. It's fast simple bla bla bla - google it. It's awesome.

1. XUnit - http://nuget.org/packages/xunit/1.9.1

XXX.WebUI

1. Cassette - http://nuget.org/packages/Cassette/2.0.0
2. Ninject.MVC3 - http://nuget.org/packages/Ninject.MVC3
3. AutoMapper - http://nuget.org/packages/AutoMapper/2.2.0

I use Cassette for asset bundling and minification. It's really small and easy to configure, plus it lets me use LESS instead of CSS so there's that.

I use Ninject for my dependency injection needs.

I use AutoMapper to map from my ViewModels and Models to my Entitie objects generated by Entity Framework.

---

Why?

A few benefits I've noticed are:

• Less folders in root. Less mental gymnastics needed keeping track of what folder is what.
• When publishing, every asset is in a single location.
• Works well with Cassette bundling and minification.

Do you have a preferred project structure? Let me know in the comments!