Do jQuery and Asynchronous calls together break the MVC Model?

Question

I marked this as Community Wiki since this might be more on the philosophical side of things, but I've been thinking about this on and off for a while.

Basically the idea is this: With MVC you have the controller that churns information, the model that carries it, and the view that displays it. It's a simple separation on paper. If I have a grid of users, the controller gets the list, the model carries it, and the view displays it. If I want to edit one, I click a link and am taken to another page. When I'm done editing, the view sends the information off through a model to the controller.

The view itself should be stupid right? I take a model and display it, then (if needed) send it back if done. However, jQuery allows a lot more than just validation messages or drag and drop. I can allow a view to call any controller it feels like to manipulate the data and display the result.

Now this isn't entirely different from the non-jQuery way as they both involve a controller and a view and talking between. However, doesn't this make the view itself become less specific in what it displays (Say an edit form for editing or a grid for displaying) and much more all inclusive like a WebForm page? Kind of substitutes in for the WebForms idea of postback and events.

Answer 1

A few thoughts...

1. A view is an abstract concept here - it might correspond to a web page, part of a web page, or just some data sent to client script on a web page. Your page could be one view, with another being the grid on it, and yet another the inline editing form for a single cell on that grid.

2. Don't get too hung up on conceptual purity; it's gonna have to break down sooner or later. You'll have client-side script to coordinate the client-side rendering of various views (jQuery, etc.) that doesn't fit entirely in any view, and in some ways acts more like a controller. No worries; don't go overboard, unless you really love JS coding... but don't feel bad about it.

3. "all inclusive" - heh. What a... nice way to describe what seems to happen all too often with WebForms pages...

Answer 2

I would agree that this is a grey area for sure.

However, if you approach your JQuery in an object oriented manner, it's generally possible to reduce the impact of any coupling happening in your View. Scripts should be referenced as resources where possible rather than writing it raw to the page, this makes them more reusable and distributable. Decisions being made by JQuery when dealing with data can, with some work, be decoupled to a reasonable extent.

Ultimately though, manipulating UI is more the View's responsibility than anything. Any code that deals specifically with elements found on a specific form I wouldn't think twice about. Imagine if you were serving the same data as a PDF file - would any of your UI JQuery logic still hold? Unlikely.

Any abstraction can leak, and MVC is no exception. But it's still a very useful and productive environment regardless of the minutia of the philosophy.

Answer 3

I don't believe that most common Javascript usage breaks the model. You are still invoking a controller method, and you are still sending data to a view in order to interpret and format it. Granted, there's some extra logic to it, but it's all view logic. It's really no different than clicking a hyperlink.

In terms of ASP.NET MVC, think of it is as asynchronously getting some extra ViewData.

Answer 4

I had a similar problem lately and I have yet to find the answer. but there are so many scenarios that prove that creating async calls from jquery is the right (or sometimes the only) way to go.

if you want to say track the number of views in a page, for example, do you enter the logic as an async call within the controller method or do you use jquery to confirm that the page has fully loaded (otherwise an error in the page will incorrectly increment the counter)

Same for a scenario where you want to refresh a set of search results (e.g. user asks to see next page of results). If you want to do this then you have to use javascript (jquery or not) to create the request to the server

I think that at the end the view is there to contain and handle your presentation logic and creating an ajax request is surely presentation-related.