On Tue, 04 Jan 2005 23:37:20 +0900, Carlos Villegas <[EMAIL PROTECTED]> wrote:
Oliver Zeigermann wrote:
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
Any idea why the java beans should be serializable?
Well, not really necessary, but sometimes it's a requirenment of the framework if this objects are passed around to remote JVMs, like in a client server scenario. Since they're simply java beans it's just a matter of declaring them as serializable.
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.
If I get this right, we could extract some code parts that simply map
peer to Slide classes and have other parts that do the peer / OJB and
possible peer / something-else mapping?!
Yes, that's about right. Also note, that if you start a new design from scratch having in mind one of these persistence frameworks, you will tend to separate strictly what's persistence from what's not and you're basically end up creating these entity classes being naturally part of your domain objects. So they're first level objects in your system architecture. And the basic guideline for entity classes is that they contain no logic at all, only data. In Slide I wasn't sure I could make the current domain objects persistent so I created this additional layer of objects which I called "peers" to emphasize that they map directly to database tables. As you say, we can analyse more carefully the current state of affairs and remove unnecessary peers and/or make Slide objects persistence frendly as required so we end up with no peers at all.
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.
I have created
http://wiki.apache.org/jakarta-slide/OjbStore
which I propose is the development Wiki page for the OJB store. Initially it contains the above TODO-List.
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]
