You're Fired

- -

I’ve never really had that much of a problem with keeping the mapping files seperately. If you’re making a change to a domain object, I can’t imagine even a fairly ignorant developer failing to update the mapping file. Even then, the problem would quickly bubble to the surface for them.

Also, take a look at this description of the different phases of round-trip development using Hibernate. I’m certainly not of the opinion that schema-to-code or mapping-to-code generation are viable in the long term. While you may have certain objects that are “value” objects in your domain, the entire point of OO programming is to encapsulate state and behavior in the same place. Good luck keeping the methods you write intact out in the wild if you’re automatically generating your domain object code!

And since the mapping-to-schema connection is quite natural, since I’m not doing anything but green field work, there’s no question which direction I’ll be going. So it all comes down to whether or not XDoclet can do everything that I’d like in terms of generating a mapping. While it may be able to, is it worth learning how? You can hand-write Hibernate mapping files easily and exactly to specification. I just don’t see that XDoclet is worth it for Hibernate. I’m sure EJB will keep it alive, but I’m headed back to manual generation of mappings for my next project.