Interview and Book Excerpt: ASP.NET MVC in Action
ASP.NET MVC in Action covers the ASP.NET MVC framework in detail as well as using the open source project http://codecampserver.com, written by the authors, as an example application throughout the book. In addition to using the ASP.NET MVC framework, the authors are also making use of the Onion Architecture, Domain Driven Design, Test-Driven Development, Inversion of Control and a lot of libraries typically used in real world applications.
The book has these chapters:
- Getting started with the ASP.NET MVC Framework
- The model in depth
- The controller in depth (PDF available on InfoQ)
- The view in depth
- Customizing and extending the ASP.NET MVC Framework
- Scaling the architecture for complex sites
- Leveraging existing ASP.NET features
- AJAX in ASP.NET MVC
- Hosting and deployment
- Exploring MonoRail and Ruby on Rails
- Best practices
By using the code infoq35 you will get a 35% discount off the book from Manning.
InfoQ: What motivated you to write ASP.NET MVC in Action?
Jeffrey: I was involved as an advisor since March of 2007. From that point on, I saw tremendous opportunity for a simplified version of ASP.NET. At the same time, I decided to point Headspring Systems in the direction of ASP.NET MVC over Castle MonoRail and WebForms (both of which we were using at the time). Because of the early experience with pre-release versions of the framework, we learned some important lessons on how to be successful using it. Because of its code-first approach, it become easy to create rich components that are reusable but also overridable. I decided to start the book project because I saw a market that was underserved. This was the Alt.Net community. This community cares deeply about quality software development but also needs to move fast. By providing a book that is heavily opinionated, and written by Alt.Net community members, this audience can quickly leverage ASP.NET MVC. Moreover, the broader .Net community could see a method of .Net development that is not the mainstream yet but growing quickly.
Ben: When ASP.NET MVC was first introduced I was immediately intrigued. I hadn't been this excited about a Microsoft product in a long time. I was determined to dig into the framework, provide feedback where I could, and share my enthusiasm with other developers. When Jeffrey approached me to co-author the book, I quickly agreed. It has been a long, tiresome experience, but one that I'll remember fondly.
Jimmy: Over the years, I've read a lot of great technical books, but a lot of bad ones as well. One of the disappointments with some framework or technology-specific books would be that they would describe the API and extension points in great detail, but would not include the "when" and "why" I would use those pieces. It's one thing to describe how to use some part of a framework, but that doesn't help you when you have to make choices on how to put the pieces together. When Jeffrey asked me to be a contributing author, he made it clear that this would be a book that we would write for an audience like ourselves. We use concepts like Domain-Driven Design and practices like Test-Driven Development in our everyday jobs, and incorporating these concepts into a book about a web framework is something I haven't seen much on the .NET side.
InfoQ: Many existing ASP.NET projects are using the Model View Presenter pattern or similar. Would this be a benefit if you want to migrate to ASP.NET MVC?
Jeffrey: Yes. Any time you can pull code away from frameworks you don't own, your software will benefit. However, implementing MVP will not benefit directly if the only goal is migration to MVC. If the goal is to migrate to ASP.NET MVC, a start would be to enable MVC pages within the WebForms project. It is easy to do, and there are several tutorials online.
Ben: Having used MVP for WebForms extensively on a couple of projects I came to the realization that all of the steps required to make it work aren't always worth the effort. Teaching junior developers the "why" of MVP is tough, especially when they are used to seeing demos of the latest drag-and-drop demoware features in Visual Studio. In WebForms, the Page has primary control of a request, and so you have to elect into the MVP pattern, consciously delegating the presentation logic over to the presenter. MVP is a valid pattern, and useful in many scenarios, but in WebForms I felt too much friction to consider it a good approach in ASP.NET.
Jimmy: Conceptually, yes. MVP supports Separation of Concerns, and Uncle Bob's SOLID principles are key to understanding why the MVC pattern is desirable over the WebForms model. Technically, no, however. ASP.NET MVC supports seamless side-by-side development and deployment, but the control and page model don't translate well into the controller-view model.
MVC makes this problem go away. By nature, the MVC pattern is highly testable and encourages good separation of concerns. Sure you have to be sure not to make your controllers too fat, but it's much easier to explain the "why" to junior devs. MVC is a much better suited pattern for ASP.NET.
InfoQ: In the book you mention the possibility of mixing ASP.NET and ASP.NET MVC. Would this be the recommended approach for existing ASP.NET projects moving towards ASP.NET MVC?
Jeffrey: Yes. This is a special case, though. You do not want to perpetually have half of the pages be WebForms and half be MVC. If you have hundreds of Web Forms pages, the work of converting all of them will be tremendous. If your application satisfies it's users, consider if the cost of porting is warranted. It may not be. However, if you just started on an application and only have a handful of screens in Web Forms, the cost of porting may be minimal, and the investment MVC will quickly pay for itself. If you are planning to move from WebForms to ASP.NET MVC, plan on doing a full migration. The application needs to be consistent with itself. You always want one and only one way of doing something within an application.
Ben: You can simply create a new ASP.NET MVC project and place your older webforms pages inside of a different subdirectory (somewhere outside of /Views). Add this prefix as an IgnoreRoute and the standard ASP.NET pipeline will continue.
The other way around is probably more work, where you start with a WebForms project and attach the MVC pieces, but it is still possible.
Jimmy: For many large applications, this would likely be the only route of success. I don't know of too many businesses that can wait 12 months or more for a new project to come online, putting on hold any new features for the existing system. Because the web by its very nature is decoupled, it's possible to replace vertical slices of a system while not affecting the overall experience of the end user. However, if a company has invested a lot of time and money into custom controls and infrastructure, these pieces don't migrate well to controllers and views. Instead, companies will likely need to re-develop these common components in the form of portable areas, jQuery plugins, partials and so on.
InfoQ: If you could change one thing with how ASP.NET MVC works, what would that be?
Jeffrey: The Html helpers. There are already many, many overloads for common input elements, and they have to be supported in the framework for many years to come. I wish the framework had provided one helper per input and relied on the community or applications themselves to provide the others. Now, when a developer types "Html.", he will see a long list of options when he will only ever use 10 of them.
Ben: I find constant frustration with the WebFormsViewEngine. I much prefer Spark, and I'd like to see that included as an "official" out of the box view engine. Perhaps even the default.
Spark offers a much nicer templating syntax. It also has intellisense, which helps immensely.
Jimmy: It's clear that much of Rails' success comes from being built on a dynamic language, Ruby. You can see places in the ASP.NET MVC design where the developers would have benefited greatly from a dynamic language, but had to resort to less-obvious means to accomplish what they needed. While not many folks are clamoring for dynamic language support in the .NET space, not many folks entrenched in statically-typed languages are familiar with what dynamic languages enable. Of course, a half-decent view engine and a real story for integrated data access in the form of something like Rails ActiveRecord would also be a great addition.
InfoQ: For experienced ASP.NET developers, do you have any tips that would ease the transition?
Jeffrey: ASP.NET MVC is just a new implementation of IHttpHandler. Leverage it as such. Also, as with any framework, get away from it as fast as possible. Write just enough code in your controllers to get to another class that you own completely. Remember, as technology moves on, you will need to port your ASP.NET MVC apps to something else. The more code you have tied up in your controllers and other framework classes, the harder it will be. Lastly, make sure to leverage MvcContrib. MvcContrib is an open source library that builds functionality on top of the MVC framework.
Ben: Read our book :) In all seriousness, experienced ASP.NET developers will have to "unlearn" some of the bad habits they have accumulated by using WebForms. For example, many smart ASP.NET developers are simply unaware of how HTML really works, because it is so hidden away from them with WebForms. They'll need to embrace HTML and HTTP; learn from other web development frameworks such as Django or Ruby on Rails; see how they are different from WebForms. They will come back with a much better understanding of why to choose ASP.NET MVC.
InfoQ: ASP.NET MVC allows you to use different view engines. What would you say is important to be aware of when considering alternative view engines?
Jeffrey: Consider long-term maintainability and adoption. You really want to choose a view engine that is going to have widespread adoption and support. You also want one that has complete tooling support. View engines are just another form of framework. Every framework you adopt comes with a cost of ramp-up for every developer that will ever work on the application.
Ben: Some view engines (such as Spark) make it trivially easy to place content in different areas of the page. For example, if you are developing a widget that needs to add a stylesheet inside the <head> tag of the page, it's simple to do so.
Another benefit is that you might want to embed your views inside of an assembly so that you can redistribute them (think 3rd party components). Spark has built-in support for embedded templates.
Lastly, I think it's important to note that you don't have to choose just 1 view engine. You can mix & match to use what is best for the given scenario.
Jimmy: Views are an investment, and a view engine is a decision that is not easy to reverse. However, MVC provides many choices, several of which are designed specifically for view development. The web forms view engine is a holdover from days when putting C# code inside your markup was a bad idea. Instead, you were encouraged to develop controls. Depending on how critical your system is, and who will be maintaining it, looking at how active the communities for the other view engines will tell you how viable those choices will be in the long run.
InfoQ: ASP.NET MVC 2 is coming soon. What is your impression of the current available beta version?
Jeffrey: The next version is great. The best thing is that it comes with VS 2010. It is also not a part of the .Net framework, so it is free to ship more quickly than new versions of the framework ship. The Areas feature is probably the most important. Areas will become the component model of ASP.NET MVC in .Net 4. You will be able to ship a single controller/view pair in a single dll or even multi-page components. The Html.EditorFor and Html.DisplayFor are promising, but it may be too much to deliver before the March 2010 ship date.
Ben: It's nothing earth-shattering. I think it's a great next step for the framework, and I believe it lays some good foundation for future versions. I fully expect to see some interesting things come out of the new Display and Editor Templates.
Jimmy: In MVC 1, it was a long way from File -> New Project to having a workable system. We had to build quite a bit on top to get to where we were comfortable with the result. This included support for strongly-typed views, areas, strongly-typed HTML builders, validation and so on. With the current beta, we're really looking forward to ripping all of that custom code out.
InfoQ: Any things you would like to add about the book or ASP.NET MVC before we end?
Jeffrey: This book contains the real world experience of folks who have been building real applications using ASP.NET MVC since July of 2008, a full 9 months before ASP.NET MVC was release. We are working on ASP.NET MVC 2 in Action at this point, and it will be on shelves in March. ASP.NET MVC 2 in Action will be planned and written out in the open via a public portal at http://github.com/jeffreypalermo/mvc2inaction. Anyone is welcome to evaluate and help enhance the code samples for the book.
Jimmy: One great selling point of ASP.NET MVC is that many of the concepts mirror those in other MVC frameworks, such as Django and Rails. That also means that these communities have likely solved many of the problems that new MVC developers have faced. It's good to understand what these other frameworks and communities have to offer, if for nothing else than to steal their ideas and bring them to the .NET space.
InfoQ: Thanks for taking the time to talk to InfoQ.