Hi Neal, On Wednesday 01 October 2003 20:53, Sanche, Neal wrote: > Hi All, > > I've been struggling with the current andromda-ejb cartridge on a > particular issue. While I think generation of Impl classes is nice, in that > inheritance is being used, the fact that the deployment descriptors need to > be 'modified' after they are generated is not sitting well with me. I was > trying to think of other ways to do it, and came up with the idea of > delegating.
You came up with the exact same idea as I :-) Reengineering the EJB cartridge to use delegation instead of inheritance is at place #2 of my todo-list, right after finally getting the car rental sample to work again. The only reason why it isn't implemented already is lack of time on my part. Well, there's a long weekend ahead (tomorrow's a holiday over here in Germany), I'll see what I can get done. Here's a couple more advantages of using delegation for the *Impl classes: - If we don't need an *Impl class (i.e. if there are no business methods that need to be handcoded), we don't generate them. This has the potential to eliminate a lot of bloat, since for the vast majority of <<Entity>> classes there is no real need for an *Impl class. - We can make the *Impl class concrete even for entities (can't do that in the current version, because the CMP/CMR accessors have to be abstract). Even better, we can make all *Impl classes implement a generated interface that decalres the business methods, and have the compiler catch changes in the model (new business methods, method signature changes, etc). Regards, Richard -- Richard Kunze [ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1 http://www.tivano.de
pgp00000.pgp
Description: signature
