Distributed Object FrameworksThere has been a lot of buzz lately about disconnected object graphs and the problems with it in the forums, and there seems to be a need for such things. Carrierwave has been mentioned multiple times, and most of the Hibernate team like it. I started this page to jot down a little on what I like/don't like about Carrierwave and collect some thoughts about how Carrierwave can be improved or how a disconnected object graph framework should/could look like.
What I like about Carrierwave:The whole idea is very nice. Especially the decoupling of client and server, and the possiblity for the client developer to work transparently on the object graph he got. So, a list of positives:
- Client/Server decoupling
- Transparent object graph handling
- Possibility to specify graph closure on load
- Transfering the graph back to the server with version checking (if I did not missunderstand)
- I like the name - very cool :)
What I don't like
- Unintuitive Concepts - lots of Image/Icon/Imageable stuff all over which is quite difficult to grasp when starting
- Code generation - There is code generation for all the Image, etc. classes. I don't like code generation ...
- Client guy has to work with the Image things, not with the "real" model classes.
- I don't like we still have DTOs even though they are auto-generated.
What might be nice ...Just some brainstorming about some things which might not be possible at all ... I was thinking about if it would be possible to do the things Carrierwave does completely transparently without code generation. Wouldn't it be possible to somehow have the client developer working with the classes forming the buisness model (eg. the Hibernate mapped classes) directly? Graph closure specification and client/server decoupling would be possible I think, the patterns Carrierwave uses can be just as easily used for a object graph not consisting of specially generated classes, and the Client/Server interface is completely generic too. Where it gets more interesting is for things like transparently reloading parts of the not loaded graph. I don't know if it would be possible to keep this completely behind the covers, for example by wrapping the buisness classes with cglib proxies. What I would love to see is a way for the client developer to simply work on the objects retrieved from the finder, and not care about the things under the cover, and probably at the end transfer the graph back to the server.
Thoughts ...It would be great if we could get some more brainstorming about this topic, probably it produces some results which could be incorported into Carrierwave or other solutions for this problem.
|