Yesterday i was going through the article from the Naked Objects about their platform and architecture. Once i gone through some of their articles and website, i had an impression that its also solving subset/similar set of problems solved by EMF.
For the ones who is not familiar with the Naked Objects, its “an open source Java-based application development platform. It’s called Naked Objects because all you need to develop are your domain objects – the Naked Objects platform auto-creates an object-oriented user interface (giving you the choice of different styles) and the underlying database (using Hibernate)“.
Thus the developer has to develop only the domain model and the UI and Persistence mechanism is auto-generated by the platform. I tried to draw some categories on which i felt Naked Objects is in similar lined as EMF.
Domain Model : Naked Objects requires the entire domain model to be developed in plain java and the domain validations to be described in each of the domain class. That means that domain class will contains the data + behavior + validations. Last but not the lease, each class must implement a NakedObject interface.
All the eclipse projects that i have worked on till date, have EMF models designed as domain models. Mostly created right from the scratch (Omondo, Together, or plain ECore Editor) or from schema. In my view i have always used custom diagnostics/validations for each domain class. In principle i do have my validations on each class.
UI Generation : Naked Objects framework does generate the Web and RCP kind of UIs. I have seen the demos of both the UI and its definitely appealing. At this point of time, i am not sure how they tackled the “Separation of Concerns”. I really like the differentiation between the View, Content and Label providers level. Not sure if we do have the access to change the editors and custom UI thats generated.
Of course regarding EMF, it does generate the Edit and Editor Plugins along with the Model. I love this separation of concerns about the Content and Labels for the Viewers. Though the generated editor does contain different kinds of editors, i am at will to change them. I can change what ever i want from this Editor.
Rapid Application Development : Yes in my view both of them does support a very fast development of applications and validation of concepts (though i have not used Naked Objects, i am making this claim on what is mentioned their site and what i have seen in demos) .
In the end i guess in both the frameworks, developers will need to change the UI. As i believe we do need some custom User Interface all the time. Every customer is unique and every customer wants a different UI.
Persistence : Naked Objects claims that it can persist the data directly via hibernate. I feel this is a real good feature, as many a times i do need a persistence mechanism. I would say this is definitely an advancement.
EMF does provide the XML and XMI as the default persistence mechanisms. I did use the Oracle Toplink as a persistence layer for EMF. Of course we do also have the hibernate support, but i have not personally used it.
Interesting thing would be if Naked Objects working with Eclipse. That means i get a similar UI and Persistence mechanism in addition to what EMF provides.
Just one correction. You stated: “Last but not the lease, each class must implement a NakedObject interface.”
This is not the case (though it was with Naked Objects 1.0). There is no requirement for your domain objects to implement any interface in order to work with the Naked Objects 3.0 framework.
Richard
You are right that EMF and NO are similar in that they focus on the domain model, but EMF relies on compile-time code-generation of the UI whereas NO operates at run-time using the Reflection API. You mentioned about content and label providers; in one sense the persistence mechanism is the content provider (it is pluggable) and the label providers functionality (eg i18n) is optionally provided by decorators. From my own experiments with EMF and EMF.edit, it seemed quite limited; certainly with NOF we have achieved much richer UIs.
However, you are wrong to state that “developers will need to change the UI”. As the DSFA has shown, it’s not necessary and may not even be desirable. That said, future viewers (one of which will be Eclipse RCP based) will allow more customisation capability if required.
Dan,
From my own experiments with EMF and EMF.edit, it seemed quite limited;
I have been on EMF for few years, it would be very interesting to see the limitations. As i personally haven’t seen any.
However, you are wrong to state that “developers will need to change the UI”.
My experiences with enterprises says that its very difficult to convince them to keep the UI thats auto generated (also the auto-generated UI could be very rudimentary). Every organization thinks that they are (and is) unique and different, so they need to have a different kind of UI.
Thats the reason that i mentioned that the developers will need to change the UI. Ok, in the end its clear that if UI generated by specific frameworks are good enough, i would not change anything.
It suits very well for the internal tools, RAD and POCs. Also i get a similar message from the FAQs from NO.
To what type of applications is Naked Objects best (and worst!) suited?.
The auto-created user interfaces give the user a great deal of flexibility and control, but the corollary is that it does take a short while to get to know that user interface. So Naked Objects is best suited to the kind of in-house application that people use intensively; it is not at all suited to applications intended to be used by people with no training (for example a public web-site). However, per the previous question, there is nothing to stop you from developing a Naked Objects application for internal users, then building a more conventional tightly-scripted interface to the same domain objects, for use by external parties.