Naked Objects

In the course of presenting Naked Objects to a new community this week, I was asked how it compared to the Ruby on Rails and/or Grails frameworks  -  a question that comes up quite frequently.

Naked Objects is similar to Ruby on Rails and Grails in the following ways:

• All three frameworks demonstrate a very high commitment to the principle of Don’t Repeat Yourself (DRY), specifically by deriving the presentation and/or the persistence layers from the domain model.
• All three frameworks favour convention over configuration as a programming model.
• All three frameworks can be used to deliver finished applications, but may also used to build prototypes of systems that will eventually be delivered on a different platform.

But there are also some profound differences.  The first difference is the intended application: both Ruby on Rails and Grails are explicitly positioned as frameworks for developing web-based applications, specifically web-based applications that have a significant dependence on structured data i.e. need to connect to a relational database. 

By contrast, although Naked Objects 3.0 does now offers a pure-HTML user interface as an optional alternative to the rich-client (’Drag and Drop’) user interface,  Naked Objects has never been positioned as a web-development framework.  The 100% auto-generated user interfaces (whether rich client or HTML) can both be highly effective user interfaces  -  but both of them require some familiarisation.  They are very well suited to applications for use inside an organisation (our experience at the Department of Social & Family Affairs in Ireland has proven this), but they are totally unsuited for applications to be used by the public on an occasional basis.  This is the distinction between what usability expert Alan Cooper  has called sovereign and transient applications.  (Of course there is nothing to stop you from developing a sovereign application using Naked Objects and then to design a more conventional user interface to access the same domain objects for a transient application).

Perhaps because of this difference in emphasis, there is also a profound architectural difference between Naked Objects and Ruby on Rails and Grails. The latter both embody the Model-View-Controller architectural pattern, with the result that much of the business logic in an application written for these frameworks ends up in the controllers.

 Naked Objects does not embody the Model-View-Controller pattern. With Naked Objects the application developer has neither the need, nor the opportunity, to write Controllers: all business behaviour must be encapsulated on the domain (Model) objects, and the framework generates the whole application from these. 

 (As an aside, when I completed my PhD thesis on the naked objects pattern in 2003, the university appointed Prof. Trygve Reenskaug from Oslo to be the external examinier.  Reenskaug isn’t a name known by many developers, but he invented the Model-View-Controller pattern.  To say that I was interested to see how he would react to the naked objects pattern is an understatement!  To my relief he really liked the thesis  - recommending that the PhD be awarded at the very start of my viva  -  and graciously said afterwards that he believed that the naked objects pattern was more faithful to original intent of MVC than the way that the latter had subsequently developed.  It was never his original intent that Controllers should end up incorporating business logic).

Thus, the fundamental difference between Naked Objects and Ruby on Rails or Grails is that Naked Objects requires an absolute commitment to ‘behaviourally-complete’ domain objects.  Both Ruby on Rails and Grails have often been described as ‘opinionated frameworks’, but the truth is that Naked Objects is even more opinionated than they, and we accept that that is bound to limit the size of the community who are willing to use Naked Objects. I make no apology for that. 

Ruby on Rails or Grails are both excellent frameworks  -  everyone I have met who uses them seems to love them.  They are easier for many developers to come to terms with than Naked Objects.  But, as I argued in the thesis, and we have clearly demonstrated in practice since, an application written in Naked Objects will achieve far higher levels both of re-use and of aglity (ease with which future changes to requirements can be accommodated) than one that separates business functionality between entities and controllers.