Naked Objects. Good or Bad

Question

I have recently been exposed to naked objects. It looks like a pretty decent framework. However I do not see it in widespread use like say, Spring. So why is this framework not getting any mainstream application credit. What are its shortcomings as you see?

Answer 1

It has been successfully used here in Ireland.

I think reasons why it hasnt been more popular are:

• You need a lot of confidence in the toolkits you are using
• It makes the GUI a risk factor instead of a no-brainer (both technically and in usability testing)
• Its not applicable to the web (as far as I know), which is where most of the focus is as present...

Answer 2

Gareth makes some excellent points.

There are other issues, such as the fact that it's hard to control the look and feel, and they are counter-intuitive to people who have become used to the window model. There is also something of a modelling issue, in that not all application domains lend themselves well to direct oject representation.

The general model of 'citizen programmer' as espoused in the smalltalk and naked object communities also comes to bear as a questionable idea. Most users don't seem to be hugely bothered with changing the functionality themselves, so thinking in objects is not that useful.

Answer 3

I have played with it last year or so, and concluded it is very easy to work with.

The strength of Naked Objectsis that you get a GUI structured according to your data model for free. The disadvantage is that a typical user does not think about his proces as a collection of records.

My conclusion was that Naked Objects is really great for an internal application which conceptually deals with records, like an inventory application or bill processing application.

If you need anything different adapting the framework to your wishes may just be a lot more work than using a framework written to support the kind of application you want.

By the way, there is a Web rendering option; see the demo at Naked Objects Demo.

Answer 4

Probably the reason it hasn't gotten more attention is that the J2EE world has become so used to piling on so many layers onto an application, that naked objects comes across as naive.

Where are our services? You mean that any naked object gives me immediate access to the database? What if we needed to expose the application with RMI calls?

Plus there isn't as much to market, because it puts the burden of developing a successful application squarely on the application developers not the framework developers :)

Answer 5

From my experience using NOF 3.0.3...

The good:

• Automagically generates an DnD UI for your domain objects, like what db4o does for persistence.
• This is what MVC was always meant to be, according to the MVC pattern creator.
• The framework only asks your domain objects (POJOs) to be subclassed from AbstractDomainObject thats all the minimum wiring.
• The framework favors convention OVER configuration: lots of annotations no freaking XML config giles.
• Works great for prototyping along with db4o for persistence.
• Out of the box functionality for Hibernate.
• In my case, I required like 30 mins from Download to Hello world app. (IntelliJ IDEA IDE)
• Deployment as JNLP, standalone, Web (NOX embedded Jetty or Scimpi flavor) and Eclipse RCP.
• The NOF team is ALWAYS there for you when you ask for help in the forums.
• The Naked Object Pattern is an awesome idea, do yourself a favor and take your time to grok it.
• Theres a lot of usability flaming going on around the Drag and Drop GUI, but if your prospective end users simply can't work with the DnD UI then you are in deep trouble anyway.

The bad:

• None that I can think of.

The kinda ugly:

• No Swing components allowed, so say goodbye to JGoodies and all your favorite Swing component sets. The UI components are custom made; to get you an idea they look like early 90's VB controls. But there's a SWT port in the works.
• The multiline line field for long strings has some issues. (NOF 3.0.3)
• DnD UI for images is kinda buggy.
• The validation code for getters n setters only fires if the domain object is modified from the UI. (This is probably wrong due to my n00bness, lets hope a NOF committer corrects me)

• If an object is modified from a non-ui thread, lets say a b.g. worker, such object will
  not update its view on screen. This invalidates a use case such as representing a mail queue in real time on the DnD autogenerated UI. (Again)

• Veikko

Answer 6

I've only just seen this. A couple of minor corrections, otherwise most of the comments are very fair.

1) 'The framework only asks your domain objects (POJOs) to be subclassed from AbstractDomainObject thats all the minimum wiring.'

Naked Objects does not require the domain objects to be subclassed from AbstractDomainObject, although that is typically the most convenient thing to do.

If you don't want to inherit, all you need to do is provide a property of type IDomainObjectContainer, and the framework will then inject an container into your objects when they are created or retrieved. The container has methods for Resolve(), ObjectChanged() and NewTransientInstance(), which are the three minimalist points of contact with the framework that you must use, so that the framework remains in synch with your domain objects.

2) 'Works great for prototyping along with db4o for persistence'. We're quite keen on the idea of working with db4o, but I'm not aware of anyone who has made Naked Objects and db4o play together. If anyone has done this, I'd like to hear more about it.

3) 'The general model of citzen programmer as espoused in the smalltalk and naked object communities ...'. We have never espoused that idea, and I don't agree with it. Naked Objects is NOT about encouraging users to program. I believe firmly in the role of the professional developer - Naked Objects just helps them to write better software and more productively.

Richard

Answer 7

• widespread use of technology has no strong correlation to technological quality.
• The nakedobject system is difficult to use in combination with type objects: if I'm selling different kinds of products and need different data for different products, it is difficult to constrain the data on the product type.
• NO lost momentum when they switched licences. (to GPL+Commercial, not the recent move to Apache)

Did you take a look at jmatter?

[edit] And another one: it makes it obvious to non-programmers if you can deliver. Spring is very much in the technological domain, NO means a developer has to talk to users. Large organisations don't do that.

Answer 8

I guess NakedObject definitely has its relevance and its more than time that developer community refocuses on what is really paying them: the business. Instead, we mostly spend our time with infrastructure, protocols and all that technical crap. I have seen such miss constructed applications and I even did some myself following the mainstream, teaching you that layering a system is always a good thing to do. The worst thing is that if you ask some developers about what kind of business the company they are working for does, you’ll find at least some who worked for the company for years without gaining a deeper understanding of the business. However, I don’t believe that NakedObject will attract a vast majority of developers (even those who are inspired from DomainDrivenDevelopment) simply because people love to construct UIs and taken that job away from them, directing their work towards businesses needs, is simply not what they want: We are all VB jerks.

Answer 9

NakedObjects (NO) are good for rapid prototyping. You can concentrate on Domain Model while not paying attention to GUI, DB and other parts of your solution. For production it requires alot of improvements (bugs fixing, data mapping, gui, etc.) in NakedObjects framework itself.

So if you need to get some kind of "proof of concept" for your solution, you may use NO. But for production be ready to invest resources into development of NO framework.

BTW, recently we are working on creating DnD viewer based on GWT for NO 4.0.

Answer 10

I've been working on the naked objects approach for over a year now and I haven't even begun to scratch the surface of the possibilities it provides for your system's architecture. To properly utilize it though, it requires that you create a paradigm shift and seek out full OO solutions and revert from resorting to functional duck tapes, because the paradigm seems to work only when you create a design that would allow for high-level development.

Having said that, I absolutely love how Django has implemented naked objects within it's Django Models. Most of the things I love about the framework have been, what I come to believe, a direct result of it's models and there are some wows off the top I'd like to share about the architecture:

Model fields, that map to table columns, are behaviorally complete objects--they know how they're represented in both the application and database domain, how they're converted between the two and how the information they hold is validated and displayed to the user visually for inputs. All of this utilized with a single line of code in your model. Wow!

Managers are attached to models and provide CRUD and any generic operations on collections, such as reusable queries (give me the last five blog posts, most occuring tags, etc.), mass delete\update operations, and business logic performed on instances. Wow!

Now consider you have a model that represents a user. Sometimes, you'd only like to have a partial view of all the information a user model holds (when resetting a user's password you may only need need the user's email and his secret question). They've provided a Forms API that exactly displays and manages inputs for only parts of the model data. Allows for any customization of the what/how in handling user input. Wow!

The end result is that your models are only used to describe what information you use to describe a particular domain; managers perform all the operations on models; forms are used for creating views and for handling user inputs; controllers (views) are only there for handling HTTP verbs and if they work with models it's solely through managers and forms; views (templates) are there for the presentation (the part that can't be automatically generated). This, imho, is a very clean architecture. Different managers can be used and reused across different models, different forms can be created for models, different views can use different managers. These degrees of separation allow you to quickly design your application.

You create a ecosystem of intelligent objects and get a whole application from the way they're interconnected. With the premise that they're loosely coupled (lot's of possibilities for letting them communicate in different ways) and can be easily modified and extended (a few lines for that particular requirement), following the paradigm you really do get an architecture where you a component write once and then reuse it throughout your other projects. It's what MVC should have always been, yet I've often had to write something from scratch even though I did the same thing a few projects ago.