Is is hard to build interactive clients going the "ultra thin" approach. "Ultra thin" does mean: the whole business logic remains at the server and has to be accessed by an external client. The problem here: interactive clients need more fine grained communication model, so more round trips are needed to provide the needed functionality. Such applications are harder to develop and maintain with the "thin" approach. There could be also some issues with performance, because of the network latency.
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.
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...
Cloudy Jakarta EE and MicroProfile: Microservices, Clouds and Beyond Jakarta EE / MicroProfile airhacks workshops at MUC airport, Winter Edition
airhacks.fm the podcast:
Stay in touch: airhacks.news.