From: Paul S. <pau...@ne...> - 2002-02-03 15:25:59
|
Daniel Bradby wrote: >> >> On the negative side, it is an extra unnecessary intrusion upon the model >> so all things considered it was probably a bad idea. A couple of people >> already commented negatively about it. >> > It doesn't force you to actually implement anything AND thanks to being > able to implement multiple interfaces, it doesn't get in the road of any > business model. It's a pain for me, and I can think of a few reasons why it might be undesirable: * adding persistence to existing code (PITA factor) * polluting "business" classes with persistence details (purist whinge) I use a "solution neutral" data management "layer" that allows me to use different persistence solutions, e.g. TOPLink or Hibernate or whatever. Having visibility to hibernate classes (or TOPLink or whatever) isn't a great idea in this situation. I know it's not a huge deal, since the interface is empty, but if there's no *need* for it I'd personally like to remove it. Some approaches advocate using it so they can tell what should be persisted, e.g. for "persistence by reachability". But since we have the mapping spec to tell us that I don't see the need. > Sounds great Paul! I've always wanted to play with Doclets and I've > never actually seen anything useful done with them. I was thinking this > was a good way to keep information about the classes together, but then > I am thinking that this seperation is part of what Hibernate is about. > Seperating your clean/pure OO business model from the OO dirty > relational model ;) > > Either way. Great thing to be able to add to a feature list. Allowing > ppl to configure via handed coded XML, plain GUI, IDE plugins AND from > source parsing. Can anyone complain? I'll get the source in order and plonk it somewhere in the next couple of days. It's only basic (i.e. it does what I needed for now), but rather than try to guess what should be in a more complete version I'll show whats there and get some feedback. Regards, PaulS :) |