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
