Practical ASP.NET
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.
At the start of this series I said that the MVC model assumes a View that is so brain-dead simple that it doesn't require testing. If I'm going to be adding significant amounts of jQuery/JavaScript to my View, can I continue to do TDD? Hasn't my View now gotten sufficiently complicated that I'm obliged to test it?
And I haven't forgotten my primary reason for using JavaScript: The ability to call Web services from the browser to eliminate the need for postbacks, except to display a new page.
I'm wondering if I should start looking at my page as a new programming environment. If that's the case, doesn't it deserve its own MVC model so that I can use TDD with it? There is TDD support for JavaScript and Microsoft is advocating a Model-View-ViewModel environment that sounds like what I'm suggesting here. Do we have two development environments: one server-side and one client-side that interact in two ways -- when the page is created and when the code in the page calls a service?
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/.