FYI: -----Original Message----- From: [EMAIL PROTECTED] [mailto:middlegen-user-admin@;lists.sourceforge.net]On Behalf Of Ampie Barnard Sent: 22. oktober 2002 13:06 To: [EMAIL PROTECTED] Subject: RE: [Middlegen-user] RE: db<->code<->uml?
My 2c: Although I use XDoclet with great success for my EJB's (Session and MDB's) I do not believe XDoclet is quite the tool for the management of O/R mapping. I have found that not all O/R mapping concepts necessarily manifest in java code (not even tagged code), for instance a one-directional compositional relationships with a composite foreign key. Thus the code->db model is not ideal. I am currently use a highly customised Middlegen to generate abstract classes representing my O/R layer for OJB. In my domain model I extend the abstract classes, allowing me to focus on business logic alone. The plug in also generates validation code, a deployment descriptor for OJB and data transfer objects. All of these are relatively easy to predict from a db-schema. So when my conceptual model changes I just update the db-schema and regenerate my code. I have however found that not all O/R mapping concepts manifest in database meta-data either, for instance lazy initialisation, caching specifications etc. Thus the db->code model is also not ideal. I think that the only place where the metadata is extensible enough is in UML. More specifically, UML has a much more elegant representation of relationships than either java code or sql code. It is also highly customisable through tagged values. So when it comes to conceptual class diagrams, I think the UML diagram should be the point of reference for the persistence layer classes, the db schema and the O/R mapping deployment descriptor (be it EJB/OJB/Hibernate/JDO). As long as the UML diagram stays the point of reference, the info bus can manage the bi-directional UML <-> code relationship (maybe using XDoclet) as well as the bi-directional UML<->db relationship (maybe using Middlegen. But I believe there will always be more in the UML diagram than in the db metadata and Java code put together. So we might want to add a field to the db or to the java code, and it then reflects in the UML diagram. But neither the Java code nor the DB knows that that field actually represents a one-directional compositional relationship that should be loaded lazily except on Wednesdays, Fridays and Saturdays between 2 and 5. This info should only be carried in UML. In short I suggest: db<->UML<->code. Regards Ampie ------------------------------------------------------- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v? http://www.sun.com/javavote _______________________________________________ middlegen-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/middlegen-user ------------------------------------------------------- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576301;v? http://www.sun.com/javavote _______________________________________________ Xdoclet-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
