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.

The 'drag and drop' user interface

In this application created using Naked Objects, each icon represents a domain object. Double-clicking on an object opens a view showing its properties and collections contained, many of which will contain references to other domain objects. Right-clicking on any object will give the user a pop-up menu of actions that they can perform.

The HTML user interface

This screenshot shows the same application being used through a pure HTML user interface. The object's properties are on the right, with the action menu on the left. This user interface was also created 100% automatically by Naked Objects from the same domain object model. The HTML user interface makes it easy to customise the look of an application (merely by editing the Cascading Style Sheet), and meets the most stringent accessibility guidelines, but it is not as 'expressive' as the Drag and Drop interface. They are both examples, though, of object-oriented user interfaces.

Naked Objects can potentially support many different styles of user interface: and several are known to be under development as independent projects.

(The screenshots were taken from an Expenses Processing application, which is included with the Naked Objects download. You may also try it out online.)

Benefits of using Naked Objects

• A faster development cycle, because there are fewer layers to develop.
• Greater agility, referring to the ease with which an application may be altered to accommodate future changes in business requirements. In part this arises from the reduction in the number of developed layers that must be kept in synchronisation. Also the enforced 1:1 correspondence between the user presentation and the domain model, forces higher-quality domain object modelling, which in turn improves the agility.
• A more empowering style of user interface. Object-oriented user interfaces offer the user much greater flexibility than conventional task-oriented user interfaces, but traditionally they have been difficult to write. Naked Objects creates an OOUI for you automatically.
• Easier requirements analysis. With the naked objects pattern, the domain objects form a common language between users and developers. This common language facilitates the process of discussing requirements - because there are no other representations to discuss. Combined with the faster development cycle, it becomes possible to prototype functional applications in real time.

These benefits are clearly brought out in the case study on the use of Naked Objects in the Irish government. For a more formal analysis of the benefits, see Richard Pawson's PhD thesis on Naked Objects.

See also: Frequently Asked Questions