Today is a good day to code

Will AJAX Break MVC

Posted: December 31st, 1969 | Author: | Filed under: Uncategorized | 1 Comment »

Will AJAX Break MVC

Picture of IrvinAJAX has done a bunch of things that are good, but as I am quite a fan of the MVC design pattern, I am a little dismayed at the problems I am having fitting my xmlhttprequest object, and the scripts that facilitate it, into my controller.

The problem is that, and the problem could be my faulty understanding of MVC, but I don't really think that's the issue. The way I understand MVC is that anything that is happening on the client should only communicate with your model, and in the larger scheme, your domain through the controller. Events therefore would always call your controller to fire. A simple example of where this would break is if a user clicked on a link to contract a div. You could use a function that would use the style.display attribute. However, the user is generating an event on the client which does not depend in any way on the controller to fire. In fact, there are events happening that affect the view without manipulating any of the back end. This is outside of MVC, but it doesn't have to be.

There are a few ways that I have figured out to make ajax fit into MVC. The first way is that all xmlhttprequests should call urls that exist in your framework. They should never call pages directly. This will provide a higher level of security and keep the xmlhttprequests in the view, although they don't really belong there.

The second way that I have thought about, but that I haven't really implemented is to create a MVC pattern within the javascript with the xmlhttprequest and the event handler mechanism in the controller layer, the scripts that paint objects on the screen in the view, and the returns from the xmlhttprequests as the model, IE the xml data or the text / html that you may be returning from your back-end framework.

The third way would be to create a bridge object to connect your javascript events to the main controller via some sort of bypass or gateway. Having a single event gateway has its drawbacks, primarily that it has to have a queuing mechanism to prevent the system from losing requests.

Problems with all of these methods… The first method only works if you have links and forms that reset the pages in order to call new sections of your application. Having the xmlhttprequests call your framework is great, but there is still way too much happening on the client without your controller having any knowledge of it.

The second method basically duplicates your model and would require you to have mirror objects and to use a transfer object to move things from javascript to your back-end language, and vice-versa. While this works, it is really cumbersome and is hardly elegant.

The last method is probably the best, but the bridge object would have to be like Fort Knox, and it would also be completely outside of MVC.

Why would it matter to break MVC? Well, it could lead to sloppy code, but if you are a well disciplined programmer then you are probably breaking rules whenever you have good reason too. I'd say that breaking MVC to deliver a better user experience, save your company or yourself money on bandwidth, and a higher cool factor would be worth it. The key would be to document, document, document. So that later when you come back to your source you don't have one of those WTF moments. I'd like to see an all javascript super-controller object, so if anyone has something like that I'd love to see it up on a site somewhere open sourced. If I can come up with anything generic enough I'll definately put it up.

  • http://Website Darío

    Good post.. I’ve been questioning myself the same over and over again. It seems to be one of those gray areas where little has been done to actually provide a proper answer.

    Unfortunately, all of the available frameworks fail in a way or another. However, I believe that it isn’t something that has to do with them but with the MVC pattern applied to the asynchronous web.