Mvc – Model-View-Controller and client-side concurrency responsibility

ajaxconcurrencymvc

In a web application that has a significant ajax component, where is the best place for the client-side concurrency responsibility to lie?

We're trying to use MVC on both the server application (LAMP stack) and the client application (ajax, mostly jQuery and unobtrusive js).

On the server-side, our model throws an exception if it finds a concurrency conflict that it can't solve on it's own. Essentially, the model tracks a revision number and date/user of creation and update. If the object being saved is out of date (older revision than in the data store), it attempts a merge. If it fails, the controller handles the exception and initiates some kind of resolution workflow.

The issue is with the client application; since ajax runs requests asynchronously, the model doesn't necessarily have the latest version of the data, but only the controller would know that–it is responsible for handling the queue/polling. The original idea was to pass all the updates fetched from the server directly to the javascript models for handling the concurrency–problem being that the lack of exceptions in javascript limits us to making flow-control decisions in the model that way.

Is it a bad idea to move the merging/model-conflict-resolution into the javascript controller? Is there a better way to handle this without the controller getting to far into model land?

Flow of the page:

User loads page(ajax application) with initial models–the models are numerous and have many attributes.
Page polls server for updates every 10-15 seconds–this is for auto-save and getting updates from other users.
User edits models.
Any conflicts that arise after initial entry are resolved when the user clicks the "save" button at the bottom of the page.

Best Answer

Not entirely clear on what you are doing. But here is what I am assuming, you are writing some kind of application with large number of users updating same values(like price of a stock) and you want to use MVC on the client stack(JS) to create an desktop application like feel.

Having concurrency control in the controller seems right. If it was me I would write the controller as a bunch of classes(functions) with extensive support for call back. If there was successful, call this, if it failed call this.

Then in the View, Ill call the controller functions with right call back functions.

Even though this will work, I feel the architecture is too complicated. Either keep the server as a model only communication(acquire lock on edit, update on save, release lock on success) or move everything to server and use JQuery ajax to just do all the work.

Related Solutions

Java – Explain Model View Controller

First I think is best talk about what is MVC Architecture and then go further into the way you are currently programming.

The MVC Architecture is way to organize the workflow inside a sotfware sistem, think about it as a layered way to implement system behaviour. This layers are:

Model: Represents your Data Model, its the system core where all information related to it should be localized. So for example: if you are going to desing a Game you'll need Players, Rules, Obstacles, and some logic related to the interactions of this elements such as : Players should be able to sort Obstacles when some set of Rules apply.

The Model is the first think you should think off because its going to be the center of your applications.
Controller: This is where the magic happens and where the Layered Architecture meets the Object Oriented Paradigm it was intended to use. Here is where you implement how does the system reacts when some application user request something about the app vai the user interface.

The Controller should be able to handle the Model Objects, do operations with them to achieve what the user requested and then delegate the result to the corresponding View Layer to render it back to our user.
View: This is the Start and End Point of User interactions. Here is where you define how users interact with the application. Nowadays is quite common users try to access, for example, web applications from different kinds of media such as: Mobile Phones, Tables, Pcs, Laptops, etc.

Generally each techonologie needs a diferent language to create the view, so imagine that your Data Model and the way that model interacts and how you render that interactions is all hardcoded, there is absolutely no way to reuse your code in a way that is not CopyPaste. The result is code that smells and lots of time wasted adapting the HOLE sysmte.

The virtude of having the View in a separated layer, allow us to work independently from the Model we are currently working on. We only need to know how we should render the list of objects the controller is sendng us. How did he generated it is completly trivial

So , finally we got an independet Model that could be adapted as we see fit according to our current needs (today i need to handle a Monouser Game with no rules, tomorrow i whan to play with friends and now its Multiuser, and so on) that not depends on how are we going to render it to the user. Then, a Controller that captures users request that came from a view , process Model Objects, and then gives the information back to the View to render it.

Back to the first question you asked: Like you can see (i hope) MVC is a WAY to do things and not a TECHNOLOGIE to create software. You could use your java Servlets, and implement a MVC Achitecture under it.

Here is a Q&A example site using a MVC Architecture to clarify a little enter image description here

Javascript – Web Application: Combining View Layer Between PHP and Javascript-AJAX

If you're going to have a significant amount of logic written client-side, then consider using MV[C]-style "separation of concerns" in your client-side JS code. For example, you might have some JS "view" logic which handles rendering:

<script type="text/javascript">
function renderUser(user) {
  $('#username').val(user.username);
  $('#dateOfBirth').val(user.dob);
  $('#address').val(user.address);
}
</script>

Then define some JS "controller" logic to pass the data into the view. The design of this depends on expected usage of the application -- e.g. if "user" is only rarely displayed, then the JS controller logic might look like:

<script type="text/javascript">
function showUser() {
  $.ajax({
    type: "POST",
    url: config.indexURL + "user",                
    dataType: "json",
    success: function(data) {
      renderUser(data);
    }
  });
}
</script>

On the other hand, if the user is displayed on every page-request, then it's non-performant to fetch the user via AJAX -- better to include the user data as part of the initial page request. You can still use the same rendering function:

<script type="text/javascript">
renderUser(<?php echo json_encode($userdata); ?>);
</script>

Or if your web-application provides a real-time list of new user-accounts via web-sockets, you could draw them on-demand:

<script type="text/javascript">
var ws = new WebSocket("ws://localhost:9998/users");
ws.onmessage = function (evt) { 
    renderUser(evt.data);
};
</script>

The examples above are a crude but hopefully demonstrate the flexibility that comes with separating MVC in JS. For a better discussion of that topic, check out a tutorial on one of the popular JS MV* frameworks (Backbone, Angular, Ember, etc).

Best Answer

Related Solutions

Java – Explain Model View Controller

Javascript – Web Application: Combining View Layer Between PHP and Javascript-AJAX

Related Topic