Skip to main content

We've Grown too Fat for AJAX

Posted by jhook on May 3, 2006 at 11:13 PM PDT

I believe we've all finally 'gotten' it. Object Oriented design with POJOs, simplified with both state and behavior, wired together with IoC flare. Many patterns outlined in the blueprints handbook just add needless complexity. Even the Java Champions mailing list had a question posted on the need for Data Transfer Objects anymore.

You're right sir, we've grown too fat with our simplified architectures. Who needs all of those layers/abstraction/patterns anymore? Just simplify, see through the needless complexity of the patterns outlined before. Why where they there? Was it to protect you from your own code or were patterns there to make up for the deficiencies of multi-tier deployment?

But now we've got this fad called Ajax-- pulling back in the concept of a remote tier in your architecture. Marshall my business Objects to JavaScript? Exposing my models for invocation over RPC? Oh, the questions you must ask.

JSON/XML Marshalling

You only are solving half of the equation. Companies spend hundreds of man hours on modeling their business in Java. Pushing only their state to the client is just providing a shell of what OO is. I may send my Line items or order to the client as a JavaScript object, but what about all of my pricing rules and other business logic? Thinking that you are safe because you are creating presentation separation in this solution is an obvious brain fart. Adjusting properties within your domain model will obviously carry behavior and you can't marshall that Java logic in XML or JSON.

If a user changes the quantity ordered of a line item or other adjustments, how is the price affected-- or even the total? Are you going to re-implement that logic in JavaScript? You have all the data there- so you should be set on your way in duplicating your business logic in the presentation tier.


Riding on the issues with marshalling your domain objects, RPC opens up a couple other issues.

First off is Security. You were safe with your existing architectures since your objects were never exposed to remote clients. You queried, processed, and rendered on the server. Now there's facilities to expose your account and ordering information directly from your domain model. While at first glance, this seems like fun, you have to wonder if you want to expose everything you've wired into your domain models. Ah, the whole DTO pattern comes back into play. Think about services. Lets say you create a DAO (as in the equinox example) that exposes things by key, or allows for lookup. Will you ever do that with your account information or orders? I would hope not. So without creating a facade and adding contextual security to prevent snooping in DAOs and services, RPC and DWR are a bad idea.

What about data? How much and when do you send it? Some of your have been able to model some pretty rich relationships with the ORM frameworks we have today-- this is good. But how much of those relationships do you want exposed via marshalling. Again, we turn towards DTOs and facades to provide bounds over our elegant domain models. I'm not going to go back into the inablity to marshall Java logic, but instead start talking about the presentation.

Presenting the data. Why did you send it to the client in the first place? Was it to display in a table? Was it to populate a form or just a couple spans? Oh boy, I have my sales history as a JavaScript array-- how are you going to create/populate a table on the screen? Calling createElement and working with the DOM in JavaScript is horrible. All of the templating technologies we have on the server-side are much more simple. At the same time, if you intended the data to be in a table on the screen, why go through the work of coordinating a DTO, an RPC method, and then the JavaScript DOM when you could've just used EL or OGNL to render this on the server-- hiding the other parts of your domain model you didn't want public. That's the luxury we afford now.

What's the Solution?

Well, I don't think we should be spinning our wheels in hopes of exposing everything we can to client JavaScript. There's been more interesting evolutions coming out of JSF, Tapestry, and Wicket with mediator architectures such that the 'presentation' decides what and when to send data back and forth between the server without ever exposing your business model or requiring the development of needless facades. You are writing a presentation to your business logic, why not let the presentation mediate all of the details for you?

Public examples of Ajax will seem glaringly obvious and without issue (such as auto completing your zip code), but I'm talking about actual business applications. With that you have to tread carefully with the technologies above, but I'm just not sure the trade-off in development is there to constitute their use. As mentioned above, there are solutions to each issue, but is it worth the development?