Review of Steven Sanderson’s Pro ASP.NET MVC Framework book published by APress

Here’s the punchline for those who don’t like to read long reviews:

This book is a must read for anyone BEFORE getting started with the ASP.NET MVC Framework. It’s well written, well edited and covers everything from the basics all the way up to security and deployment. Finally, the point that sets this book apart from most other technical books is the tutorial included with the book; Steven Sanderson makes no compromises in the tutorial just to “dumb” it down for novices.  Using Test Driven Development (TDD), Dependency Injection (DI or IoC) and Unit Testing as well as basic Object Oriented (OO) principles like Don’t Repeat Yourself (DRY) and separation of concerns, the tutorial is a useful example of how to build a real life application for maintainability. They don’t teach even a tenth of this stuff in most technical courses.

The book is broken down into two parts – An introduction to ASP.NET MVC and a detailed look at ASP.NET MVC

The first two chapters start with Steven Sanderson gently holding your hand as he guides you towards creating your first ASP.NET MVC project. Quite a few technical books intended for novices and intermediate users struggle with presenting the information at the right pace. The author however, has mastered the pacing for presenting information. There’s always enough information to keep you going, yet he also goes deep into the matter at hand to explain how things work under the hood.

The third chapter is what sets this book apart in a lot of ways. The book goes into enough detail about automated testing, inversion of control and domain driven design and how they all fit together. More importantly, the book shows you just why these techniques are pragmatic approaches to create maintainable applications. The application presented in the next three chapters builds upon those techniques to show you how many modern thinking programmers build maintainable applications nowadays.

The rest of the book delves deep into the inner workings of ASP.NET MVC and covers a wide range of topics including routing, security, AJAX and deployment. After reading this book, you should know enough to start building robust, maintainable applications using ASP.NET MVC

If I sound like a huge fan of this book, it’s because I read a lot of technical books, but rarely do I find a book that’s so well written and more importantly strives to teach the reader how to build maintainable applications using modern techniques like Test Driven Development or Dependency Injection.

While almost flawless, there is a problem with this book. The people who seek out ASP.NET MVC on their own are people who have already worked with and been burnt by working with ASP.NET WebForms. These people are also usually people who know about and appreciate Domain Driven Design, Test Driven Development, Dependency Injection etc. This book isn’t going to magically convince beginners of the benefits of these techniques. Rather, this book is really targeted as an introduction to seasoned programmers who want a hands on and detailed introduction to ASP.NET MVC.

Suggested solution structure for ASP.NET MVC

Working with ASP.NET MVC, I’ve come up with a solution structure that works well for most projects. I’ve also included a reasoning for my choices, instead of just telling you how I’ve arranged my projects within the solution.

One of the major design goals for MVC is a strict separation of concerns. Your solution structure should reflect this. By using multiple projects, one for each concern, we can make sure that it’s easy to identify when concerns are being mixed.

  • Models – The M in MVC, this contains all your business domain classes. There should be persistance or web service related classes here. If your classes require database acecss, it should be through Interfaces defined in this project. A quick way to check if this project is “clean” of data access is to check if you require references to data access DLLs like NHibernate. If you do, you’re mixing in data access with your business domain models. Reason: You should be able to take this project and plug it into any other solution, for example if you want to use these domain classes with a different UI like a WinForms application.
  • Controllers – The C in MVC, this contains all your controllers as well as your ModelBinders. Reason: Having three separate projects for Models, Views and Controllers makes the separation of concerns explicit and makes it harder for leakage of concerns.
  • Site – The V in MVC, this project contains all your views and master pages. This also contains all the content needed for your Web UI, including your JavaScript, CSS, images etc.  Reason: This project holds all the views and resources (JavaScript, CSS, images etc.) that constitute the Web UI. Again, by having a separate project for the Views, the separation of concerns between the View, Models and Controllers becomes explicit.
  • Tests – This project contains all your unit tests, functional tests, integration tests etc. Reason: Keeping all your unit tests in a separate project forces you to test only the public interfaces exposed by the rest of your projects; a good practice for unit tests in my opinion.
  • Services - All persistence related code go into this project.