My search for the User Interface Holy Grail led to to nakedobjects.
At first it looked promising, it was little convincing. But delve deeper and try developing prototypes, then you find its just another paradigm.

Let us look at the fundamental premises of nakedobjects.

1. All business logic should be encapsulated onto the domain objects. This principle is not unique to naked objects: it is just a strong commitment to encapsulation.

Apart from applications where all the logic neatly fits into the domain objects, it is far from feasible to encapsulate all business logic within domain objects. There are two schools of thought regarding Domain Objects. One, that considers Domain Objects as describing the Domain entity attributes and their relationship with other domain objects whereas the other school of thought is to put all the business logic into Domain objects.

Applications like Mail applications, that are single user centric, fall neatly into the category where the domain objects could hold all the required business logic.

Why is that in complex applications it isnt possible to put the logic neatly into their domain objects ? If not in the domain objects where else do we have them ?

The complexity is due to the complex interplay of the domain objects. Certain behaviour arises out of the interplay and cannot be neatly decided as to which domain object “owns” the behaviour. It is precisely this nature of interplay that breaks the rule that business logic could be neatly packaged into their respective domain objects.

In some architectures, domain objects, are materialized from the databases. So domain objects are considered as mere data representations.

Now, to answer the next question – If not in the domain objects, where else do we have them ?
Simple and short answer : Services

Services hold in them all the business logic. Services are reusable, UI agnostic piece of software. It is based on well defined contract and hence quite robust. I agree that in a OOP language like Java, these so called services are also classes in the technical sense. But learning to logically separate domain objects and services gives one a new perspective towards application development.

Now, let us look at the next premise of nakedobjects.

The user interface should be a direct representation of the domain objects, with all user actions consisting, explicitly, of creating or retrieving domain objects and/or invoking methods on those objects. This principle is also not unique to naked objects: it is just a specific interpretation of an object-oriented user interface (OOUI).

The above definition seems to make sense to us if we replace domain objects with services. It is at the services level that a meaningful UI application exists.

Even then, I feel it oversimplifies a whole gamut of things. Generating User Interfaces from either domain models OR Services isnt still straight forward. User Interface is not just about seeing and manipulating data but there are other things like Usability, Interactivity, design, style and aesthetics.

How can one handle the Processes ? Processes could be a set of services invoked sequentially (or even parallely) based on certain conditions. Enterprise class user Interfaces usually operate at the process level. Clearly, it looks like the Process space is beyond the purview of nakedObjects.

The idea of this post is not to shootdown the idea behind nakedObjects. But to highlight its position in the complete enterprise UI problem space. To understand what kinds of problem it solves and to understand what is left for us to be solved.

The nakedobjects may be the first step towards a better UI. Bigger enterprises have made headway into this approach and show much more promise. SAP, for instance, has come up with such a idea. You can find more details here.

When we move from Business Applications and jump into the Composite Applications bandwagon, such an approach that deals with services first and then a UI for the service allows for more flexibility and allows for a mix and match of Composite Application offerings.

In one of the next posts, I shall write about declarative business application development. It seems to holds a lot of promise. We shall investigate this approach and validate if it is yet another bubble or is it something ground breaking.