Evil Getters and AJAX

    A couple of years ago, I read a great article by Allen Hollub called "Why getter and setter methods are evil." If you've never read this, I highly recommend it. Let me give a very quick synopsis. Exposing data via accessors (getters and setters) causes tight coupling between components in your code. So if something changes about your data, then many other components must also be changed to accommodate this change. So getters and setters are evil.
    That's all well and good, until we start talking about UI. Most of the UIs out there, whether they are desktop applications or web pages, use an MVC paradigm. This inevitably leads to your view calling lots of getters on models to display data. Similarly your controllers wind up calling lots of setters on models to process input. So MVC requires lots of getters and setters.
    So is MVC evil? That would be a problem because it is the de facto standard in UI technologies. Let's just concentrate on Java web apps for the moment. Struts and JSF are both MVC based frameworks. My new personal favorite UI technology, Spring MVC is also clearly and MVC framework.
    The more object oriented approach to UI would say that objects should know how to render themselves. If they know how to render themselves, then other components (views) do not need to call getters. These objects should also know how to construct themselves. So their components (controllers) do not need to call setters. This is clearly against MVC which says that the view of an object needs to be separated from the object.
    Holub's original article caused quite a stir. He stuck to his guns and presented an alternative approach to MVC in a follow-up article last year. Here he suggested that a Builder Pattern be used to build different representations of an object. This could an include an HTML representation to be used by a web app.
    This is a clever idea. I liked it quite a bit. However, when I read it, I could totally see an experienced UI developer looking at all of these builder classes that had a lot of nasty code to build HTML strings, and thinking "this is stupid."
    Something has changed this year that may change people's minds. That something is AJAX. One of the many things that AJAX encourages is the ability to render on a much more granular basis. You don't want to always re-render an entire when a request is processed. Instead you need to be able to just re-render the parts of the view that have been affected by the request.
    I saw an article on TSS about adding AJAX to an existing Struts web app. I couldn't help but be amused by their ridiculous strategies for doing this. They recommend re-using your view, but putting lots of if-tags in so that only parts of the view can be rendered based on data in a request. They then recommend using the request.responseText so that you can just dump the HTML from your view directly into your page.
    To me, this just shows the limitations of the MVC approach. The view object is the only thing that can be rendered, so everything has to go through it. These views are supposed to correspond to web pages, so a lot of hacking has to be done to turn a view into something that is not a web page and can be used by AJAX.
    What if you didn't have a Struts app? What if you had crazily taken Holub's advice and gone with a builder approach instead? One can imagine that your life is suddenly a lot easier. To use AJAX, you can easily just ask your sub-component to render itself and send that back to the JavaScript handler on the page. It can also render itself as HTML or as XML, allowing you to use the more powerful request.responeXml object. It is not only easier but much more natural to adopt AJAX to a web app that does not use MVC.