Recently at work we have been having the discussion about using AJAX (Asynchronous Javascript And XML) to help us out with certain usability issues on some of our applications. I had an interesting discussion with a colleague about whether or not using AJAX breaks the MVC (Model View Controller) design pattern that we are all so comfortable with. The application we were discussing was using Struts and so followed the MVC pattern without implementing any of the functionality using AJAX.
If I understood his argument is was basically that if anything but the controller handles an event then the MVC pattern has been broken. Clearly we do this in an AJAX application where some user events would be handled by Javascript libraries and others would ultimately make requests to the application and therefore be handled by the controller.
It seems to me that the same argument could be made of any web application that uses DHTML that reacts to user input. So even graphical buttons that change state based on whether a user is hovering over it or clicking it is an event that causes a change NOT handled by the controller. Even something this trivial would break the MVC pattern.
So maybe the more important question is to what degree or in what fashion is it okay to break or modify the MVC pattern. From my point of view it makes sense for events that invoke ONLY view logic to be handled by the view. So to have sort of a "Smart View" instead of the traditional dumb document or form that is usually returned in an MVC web application. This allows for much more responsive views that will immediately respond to user input. This level of responsiveness is not generally possible in a web application where events are processed over http.
So where do you draw the line? A "Smart View" should only contain view logic. There are obvious security risks to allowing business logic to be handled in the view so obviously that road is closed. I'm curious if this has been a common theme to others implementing AJAX on their web apps.
2 comments:
I don't see how an ajax call breaks the MVC of the server side? If you do a traditional Struts MVC, you have action classes that are glorified "extended" servlets.. they handle the incoming requests and delegate to the logic to do something.. then forward to a JSP page to go back as the response as the "view". An ajax call would be no different than any other link call.. you'd call an action handler (and you would map them in the struts-config like any other request... be it a form, pge link, etc). So, really, your javascript is on the client side.. it's not part of the MVC. Because of that, the ajax call, on the client side, sends a request to the "mvc" struts app and as far as the struts app is concerned there is no difference. I replaced using form submits with ajax calls. The struts app was not changed.. other than that I don't use any special form validation stuff within Struts.
Hi Kevin!
I agree with you that a straight AJAX call does not break MVC. I also realize that under some definitions of MVC, the controller ONLY controls calls between the view and the model. However, in some UI development, desktop ui for instance, you would typically use the controller for handling ALL events not just events that interact with the model. My point was that it's more DHTML than AJAX that would violate that concept. I think it's completely acceptable to have view events handled within the view.
Post a Comment