An Introduction to Naked Objects

A typical four-layer architecture

Most modern applications consist of four or more logical layers: a presentation layer (blue), a controller layer (red), sometimes referred to as the 'process', 'task' or 'use-case controller' layer, a domain model layer (yellow) consisting of domain objects and/or supporting business services, and a persistence layer (green), typically a relational database. Even in a so-called 'thin client' architecture, all four layers typically exist, but all on the server. Each new business concept must typically be implemented in four separate places. And because the linkages between the layers is often complex, a change to an existing business requirement will often entail tracking up and down the layers many times.

 

Object-Relational Mapping

With Object Relational Mapping (ORM) technologies, it is now possible to auto-generate the persistence layer directly from the domain model definition, thus eliminating the need to define and maintain one whole layer. Naked Objects uses Hibernate to perform this function.

The real innovation of Naked Objects, is that we apply the same concept upwards - to eliminate the two other layers also...

 

Behaviourally-rich domain objects

The first step is to ensure that all the business logic is encapsulated as methods on the domain objects. Thus, a Customer object should not just be a collection of data about the customer; it should encapsulate all the behaviours that we need to apply to a customer. This is not a new idea - it is merely a very strong commitment to the principle of encapsulation - but most application developers pay lip-service to it, with the result that most of the behaviour ends up in the controllers. We refer to this as creating 'behaviourally-rich' domain objects - which is why the (yellow) domain objects are represented as solid spheres in this diagram and below.

 

Naked objects

The conceptual breakthrough is the realisation that once you have behaviourally-complete domain objects, it is possible to auto-create a complete user interface, just by exposing the domain objects (with their methods) directly to the user, in the form of an object-oriented user interface (OOUI). At run-time the Naked Objects framework inspects the domain objects using reflection, and then renders the objects and methods visible to the user. Writing a Naked Objects application therefore consists solely of writing the domain object model, as 'Plain Old Java Objects' (POJOS). This concept has become known as the naked objects architectural pattern. The Naked Objects framework is the leading open source implementation of this pattern.