OK, I will remove the author tags then. Concerning DAO, I was talking about the general concept, while you seem to think about the Spring implementation. Is that right?
Well I was just saying that in this imperfect world you can't just map any object to a relational model. Comming from EJBs and entity beans you are taught to keep your persistence (entity/peer) classes simple, simple serializable java beans. Just binding your java beans properties to fields in database tables. This way you can query your persistence classes in the same way with some abstracted SQL that eventually gets mapped to native SQL. But this way you still have to do abstraction mapping at the java level, between your domain objects and your entity classes. That's the approach I've taken, which is pretty standard, used in EJB and OJB. I haven't really explored DAO, ODMG or Spring so maybe these frameworks have less limitations in this respect and you can go closer to your domain objects. My first purpose with OJB was to remove database dependencies as much as possible. Let OJB take care of the database differences, that's all at this point. We can explore later the possibilities of using these frameworks in Slide in a cleaner design.
Anyway, this is our TODO-List, right? - Content support - Native Sequence support - Compatibility with the old scheme (maybe using a migration tool) - Think about mapping
Yes. That's it so far.
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
