Test Driven Development in ASP.NET MVC
Peter Vogel raises some interesting questions that address one of the major benefits of ASP.NET MVC: Test Driven Development.
In my last column (ASP.NET Processing in ASP.NET MVC
) I pointed out that if you like the dynamically generated HTML that you get with, for instance, the ASP.NET GridView, then you may not be happy with the amount of HTML you'll have to write yourself in ASP.NET MVC.
But that issue may be missing the point: It's an AJAX world. Rather than returning to the server to get new HTML when the user performs some action, it may make more sense to manipulate the HTML using jQuery UI directly in the browser. In that scenario the standard ASP.NET controls actually get in the way. Right now, I'm going to have write that jQuery code myself because the tools for managing HTML implied by this paradigm don't come with either ASP.NET or ASP.NET MVC. At least, not yet.
So, here's the tradeoff: As I build up a re-usable library of function-rich, jQuery-enabled HTML solutions for managing client-side interaction, I'm going to be less productive than I would be with ASP.NET where that's provided in a server-side environment (with a little bit of AJAX overlaid). That means that, if I stick with "pure" ASP.NET, I may be more productive, but I'm also going to be delivering less-interactive applications that -- because they make more use of the server -- are less scalable than the equivalent AJAX application.
Do I believe that the new generation of AJAX-enabled ASP.NET controls will let me get to the level of interactivity that the new jQuery world offers? I don't know yet. I'll have to wait and see on that.
If I stick with ASP.NET, I'm also going to be less able to do test driven development (TDD) than I will in ASP.NET MVC. I know that I'm more productive with test driven development. Does the increased productivity from TDD outweigh the time spent in enhancing my UI? And that question actually leads to the key question for me.
That's a lot of questions that I'll have to return to later (and I'm not claiming to have the answers). It's time to return to this column's mandate: ASP.NET. So, in my next column, I'll be looking at Microsoft's latest solution to managing your Web.Config file when moving to production.
Read the other entries in the series
ASP.NET MVC for the ASP.NET Programmer
Controlling Controllers in ASP.NET MVC
Viewing Views in ASP.NET MVC
Managing Models in ASP.NET MVC
ASP.NET Processing in ASP.NET MVC
About the Author
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.