Hi Herve, (cc: Jos), finally, I have found some time to check your submission. I found that all this is well designed and usable. There is some overlap with the AndroMDA Hibernate cartridge, for example your DAO classes do more or less the same thing that the factory classes do which are generated by AndroMDA. Your DAO classes contain some more methods, though.
What I was really missing was a light-weight replacement for the session beans that we currently generate as a session facade for components that are written using Hibernate entities. Our session beans open and close transactions and Hibernate sessions. Opening and closing Hibernate sessions could be replaced by your thread-local storage solution that I find quite elegant. But what about transactions? And: Our car rental sample demonstrates that MDA can be used to generate totally different implementations from the same model. I'd like to continue to keep that promise by making sure that the SAME web tier code uses two different implementations of the business tier code, one with EJBs, the other with Hibernate. Do you see a possibility to generate Hibernate session facades which have exactly the same interface as the EJB session facades plus their possible business delegates? If the answer is yes, I see the following possible steps now: 1) The Java cartridge should be enhanced to generate business interfaces for a <<Service>> class. 2) The EJB cartridge should be enhanced to generate business delegates for <<Service>> classes. These should implement the business interfaces generated by the Java cartridge. 3) The Hibernate cartridge should also be enhanced to generate light-weight session facades for <<Service>> classes. These should implement the SAME business interfaces generated by the Java cartridge. 4) The web tier of the car rental sample should be adapted to use the business interfaces only and continue to be agnostic about which technology runs behind them. 5) The car rental system sample should be 100% running again in both technologies. All this should possibly be done in AndroMDA 3.x because it changes the API of the generated code significantly and would require users to change their code. Ideas on this? Volunteers to do it? Cheers... Matthias > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Herve Tchepannou > Sent: Friday, November 28, 2003 1:54 AM > To: [EMAIL PROTECTED] > Subject: [Andromda-user] AndroMDA cartridge for DAO + Hibernate 2.x > > > I'm submitting here the cartridge that I've created for my > application that is not dependent on any EJB. This cartridge > generates code based on the DAO design pattern. For each > entity, the following classes are created: > - a DAO interface that contains CRUD methods > - an implementation of the DAO interface based on Hibernate. > > This cartridge is based on the following assumptions: > - each com.foo.dao.xxxDAO methods throws > com.foo.dao.DAOException (that is not generated by androMDA) > - the Hibernate implementation use the ThreadLocal design pattern (see > ttp://www.hibernate.org/42.html) > > For this cartridge, I have added a couple of things for > customizing the > codegeneration: > > - Tag value for setting the table name: @andromda.hibernate.table > - PK are assumed to be of type long, so the PK generator is > the native. So it supports auto-number, sequences or hi/log > generators, depending on the target database > - Add the method 'findAll()' int the DAO interface > - Add the following attributes tags: > * @andromda.hibernate.length > * @andromda.hibernate.unique > * @andromda.hibernate.not-null > > ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Andromda-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/andromda-user
