The best (and next best) possible advice I could give you about using the MVC framework

Posted by Jeremy Miller on September 11, 2008

I ditched quite a bit of some complicated server side state management / screen workflow around the MVC framework today in favor of just a little bit of client side code with the jQuery.Form component.  The lesson learned today for me, and not for the first time, is to keep your MVC framework usage and the server side views as simple as possible. Take all that time you saved on fancy server side work and apply it to serious jQuery-fu.  I would have positioned our design so much better upfront if I’d just taken the freakin’ jQuery in Action book home over the weekend early on our project instead of doing so many deep dives into the MVC code.

Of course, since we’re doing so much more jQuery coding on the client, it’s making it more and more important to test the UI in multiple browsers.  I hit one of those cases today where something worked perfectly in Firefox (what I think all of us use day to day) but not in IE.  We already use QUnit quite a bit for unit testing client side Javascript, but it’s only running in IE during the CI build.  We also have end to end tests with Watin, but again, that’s IE only.  I think we’ll make the minor move to write a QUnit/Firefox runner for CI, and I think I’m going to go take a much longer look at Selenium RC which supports multiple browsers for the end to end testing. 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller

    @Ricky,

    Part of the point of this post is that some of the CORE functionality has turned out to be easier and cleaner to implement with jQuery that it would be with server side state management. I’m not talking about flashy/glowy stuff here, I’m talking about data entry mechanics.

  • http://rickyrosario.com Ricky Rosario

    I agree that jQuery/JavaScript can make things easier, but I think you need to get all the core functionality to work first before introducing a single line of JavaScript. Progressive enhancement!

  • http://paulbatum.blogspot.com Paul Batum

    Any chance of a follow up post on this Jeremy? I’d love to see an example the server side version vs the jquery version.

  • http://zymen.net Boguslaw Faja

    Selenium supports firefox too. I use it, and it’s amazing tool. For me, the best one.

  • http://blog.goeran.no Gøran

    Hi Jeremy!

    I used QUnit to test a few jQuery plugins I wrote, and the developer experience was good enough. Let us know if you’re thinking about to release the bits for the QUnit test runner!

    I totally agree with you on keeping the server side views as simple as possible. I also use lots of jQuery-fu (as you call it) in the view. That’s why I’ve developed a few jQuery plugins for MVC to ease the gluing part between the view and the controller on the server side. It can easily be modified to support other MVC based web frameworks as Struts, RoR or monorails. You can read more about it here: http://blog.goeran.no/PermaLink,guid,e55bfb55-ac10-48db-98a4-d28343e0f98a.aspx

    Feel free to use the code as you like! I would be very happy if you find it helpful and you can use it in your project.

    Keep up the good work!

    Cheers

    Gøran

  • Julian Jelfs

    Sounds like we have gone down a very similar route. We are generating client side views composed from individual js components. This is all generated off the server side view (ascx). I found that QUnit was lacking in its support for asynchronous scenarios of which there are many (particularly if you start using visual effects). In the end I wrote my own which is very similar but allows you to specify how many assertions the test expects and doesn’t evaluate whether it has passed or failed until it receives those assertions. This enables you to support longer running tests without a problem. We drive our js tests by having WatiN run them from an nUnit test (which allows us to plug into CI).

    This style of development raises a big question that I’ve never had answered. How do you deal with the client-server divide when trying to do MVC in the web scenario? Do you have a client view, client controller as well as a server view and server controller? Thet’s kind of what we do.

  • http://computeristsolutions.com josh

    I’m a big fan of jquery, but have this lingering reservation about trusting client side script too much. Do you forsee any vulnerability to attack or data-integrity in using jquery for forms this way?

  • http://www.ayende.com/Blog/ Ayende Rahien

    Agreed.
    Note that Watin also work with FireFox, if you install a Firefox addon.