Here's another design pattern/framework idea I hadn't come across before. Its called Naked Objects. Not sure why they call it that, but here it is in a nutshell:
1. All your business logic should be strictly encapsulated.
2. Your user interface should be a direct representation of these objects. IE the GUI should only call upon those objects.
3. The GUI should be generated from the definition of those objects, using code generation techniques or reflection (preferred).
This could be combined with ORM such that you would only define the domain objects and the GUI and Database layers would be generated from that, though this is not part of the definition.
I am not sure how well this would work. It almost sounds like it could lead to the same sort of mis-match that occurs with ORM. What if your objects have much more functionality (say, to support a very robust API) than you want to expose in a default GUI? How would you enable a graphic designer to make cosmetic changes to this auto-generated GUI?
At any rate, it's another interesting concept. And frankly, I like the name.
1 comment:
With Naked Objects 3.0 if your object has (public) methods that you don't want exposed to users, you just mark them as @Hidden. Also, the visibility of all methods can be controlled via authorisation i.e. role-based.
The 'Drag and Drop' UI for Naked Objects is not easy to alter, but Naked Objects also provides an auto-generated HTML UI, for which your graphic designer can simply provide an alternative CSS.
Post a Comment