Fat AJAX Applications vs. Smart Native Clients. or the wrong direction of the hype. 📎
Fat Clients, or more using a more political correct name: Smart Clients, do not have such problems, because the domain objects reside in the same address space as the presentation tier. Fine grained communication isn't really a problem - there is no network in between the UI and the business logic. Validation can be implemented in the domain layer, no redundant implementations are needed. The application is "DRYier", than in the thin client approach, were because of performance client- and serverside validation is needed.
So accessing domain objects directly, with no additional layers of abstractions (factories, interfaces etc.) is much more interactive, faster easier to build and maintain. Of course we have to check first, whether such a client can be deployed easily and cheap to the clients.
In a "Fat" environment, it is even possible to directly decorate domain objects with UI. Such approach is no more possible in thin client-server environment, because all calls has to be routed to a coarse grained facade. It becomes even worse with Fat AJAX applications. In this case JavaScript-UI event has to be translated into a JS domain object, which is serialized using JSON or XML and sent to the server. From the JSON/XML stream a Java Object has to be constructed. This many indirections and layers are not very good for clean and easy design. You have also validate the user input twice: on the client- and server (in two different languages...):
The motivation for this short article comes from the following entries:
Thank God - Java EE Is Not Like Ajax
Different AJAX Philosophies and Architecture Styles or Thin vs. Fat AJAX
The beginning of WEB 3.0 with Java Fat Clients
The Day After AJAX
Return of the Rich Client - .NET 3.0 Meets the NY Times
First Look Times Reader
Especially the comments are very interesting...