This is something I started to think about the other day as I have been diving deeper into MVC. In it’s purest form, at least to what I understand, is that the whole idea of MVC is to have a separation between information handling (controller), information delivery method (model), and the information presentation (View). What this means is that the View itself should only be around to display or return information, but that’s it. Have a form? Great, here’s the information you need to fill out and I’ll send it on it’s way. And even with that idea, the View itself doesn’t really send anything. It just passes what it knows off to the model and it’s back in happy land. (The view gets nervous sometimes… performance anxiety) The whole system works well in actuallity, it does what is expected. There are no events simulated and possibly tangled. There’s no smoke and mirrors when it comes to the display and what the user is seeing. I want a grid of users? Here it is. I want to edit this user? Great! I’ll take you to the page that does that. Life is great and wonderful.
But wait, here comes jQuery, Json, and Asynchronous Calls. Now I can do crazy things with the view that I could never do before. Remember that grid of users? Well you don’t really have to go to another page to edit. Hell, just click this link and a form can appear to take in what you need to change. Even better, the grid itself will change and allow you to edit any row you want, and when you’re done the grid will come back all new an refreshed. What a crazy party this is now. Kind of sounds familiar right? Yeah WebForms. With these three helpers we’ve now cut out the middle man in the Model and passed the savings onto you. Essentially the whole idea has been chucked and jQuery has allowed us to invoke the same event model WebForms was chastised for. In fact, you could go to the logical end and have one page once again that controls everything. The View once again has the power much like it did in WebForms (provided you look at the Page and code behind being more like a View than separate entities). Isn’t that the whole thing we were trying to get away from?
I suppose you could make the argument that no one is putting a gun to your head to use jQuery for anything other that simple things like UI manipulation (date pickers, sliding controls, drag drop, ect) but that wouldn’t be the situation being argued here, now would it?
I agree with your point, but having the option to use async. calls is more valuable than abiding by a strict MVC pattern. It really depends on the application. For a traditional app, jQuery can complicate things, but for a social networking site, jQuery is Almighty! Just my 2 cents.
Nice post.
Totally agree. So far I’ve seen the crazy good stuff jQuery and async calls can do, but I can’t help but feel unpure.
There are many webapps that use a single “view” page and use async calls for the entire app. Gmail, for example!
But yes, there are pros and cons to not adhering to MVC, but there are other aspects of MVC that are not common, such as the fact that the model should be able to update the view. Unless your website does some form of long server side connectivity (long polling, comet etc) you can’t get complete MVC anyways.
JQuery makes *so* many issues easier, but its up to you to decide how clean you implement your architecture 🙂
I agree… However, you could create a client side mvc in javascript. Then you’ll have a two tiered app with an mvc base on both client and server.
Reeealy?
So what’s stopping you to have jQuery manipulate data via a controller, the same controller that is yours truly used by any honorable VIEW?
jQuery means jack in terms of MVC.
One of the things I’d point out that often seems to be overlooked in these lines of thoughts is that there is back-end and front-end, and each can ( and arguably should ) be able to follow the same separations of concerns.
Chastising Javascript ( via jQuery ) for controlling front-end behavior is like chastising CSS for controlling front-end appearance. Strictly speaking you could have a basically flat HTML site that could still implement the basic MVC architecture. The HTML represents your Model / data, the CSS represents the View / presentation and the Javascript / jQuery represents the Controller / interactions.
Just my $0.02. =)
Actually, if you architect it right, then you are still staying true to the MVC paradigm. In your typical page request/response your controller action spits back a view to your user. However, you can modify the same controller to take an additional parameter informing the controller that only a partial view (or JSON) should be returned. The controller, model and view are still separate, but you get the additional benefit of an asynchronous request/response.
Just because jquery is client-side, doesn’t necessarily make everything jquery be “of the view”. If it’s useful to leverage jquery to encapsulate some model responsibilities, then you can view the client-side as a big ‘V’ plus a small ‘m’ & ‘c.’ Less ‘pure’? Well, do without jquery, I pity your users. 😉 And asynchronous calls don’t event warrant a mention, it’s just an improvement in communication. Nothing less ‘pure’ about it whatsoever.
@Mike J
“Chastising Javascript ( via jQuery ) for controlling front-end behavior is like chastising CSS for controlling front-end appearance.”
I guess the question with me is the seperation between just manipulating the current data given by the UI (Hide/show, cute little animations, ect) and actually getting and updating data from various sources on the same view.
It was my understanding that people were championing MVC because of the “What you see is what you get” like construction that gets away from things like ViewState and PostBacks to present a more pure page. Using jQuery to manipulate the UI fits fine into that. Adding jQuery and Asyncronous calls, to me, starts to become that which WebForms is so hated for.