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.
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...
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.
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.
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.
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.)
Developing a business application using Naked Objects offers four principal benefits:
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