rtayek wrote:
RobJellinghaus wrote:
Because the merging would be a huge pain in the rear and very error-prone. Using <meta generated-class> lets subclassing do the work,... We have been using this technique for a month or so now and it is truly wonderful.
that was my plan, but the boss wanted the code to go in the generated class. am reading the above right in that you can get hib to your subclass?
Yes. The pattern is:
Code:
<class name="your.MappedClass">
<meta attribute="generated-class">your.generated.MappedClassGen</meta>
....
</class>
Then hbm2java spits out your/generated/MappedClassGen.java:
Code:
package your.generated;
public abstract class MappedClassGen {
...
}
And *you* write your/MappedClass.java:
Code:
package your;
public class MappedClass extends your.generated.MappedClassGen {
...
}
You put your code in MappedClass.java, and you regenerate MappedClassGen.java whenever the mapping changes. It makes no sense to put your code in the generated .java file because, well, it's *generated*! :-) And you want to be able to *regenerate* it without messing with your handwritten .java files. Feel free to show your boss this thread ;-)
Quote:
just so i am sure, then there is a way to tell hib to map the row into to the *derived* class, but to generate a the base clase and let the compiler ...?
Yes, this is exactly what happens: Hibernate at runtime *only* knows about your "your.MappedClass" derived class (since that's what your <class> element actually maps).
The generated class is just an implementation detail which hbm2java happens to make for you; you (and Hibernate) never make instances of it (it's abstract!), you (and Hibernate) only ever make instances of your concrete subclass.
Quote:
hmmm, i though they did crud and ome find :(
I guess traditionally they do, but with Hibernate, you create objects with "mappee = new MappedClass(...); session.save(mappee)", you update them with "session.update(mappee)", and you delete them with "session.delete(mappee)". We have a Persistence static object which uses the thread-local-session pattern to hide the Hibernate details; so our code just does "Persistence.save(mappee)", "Persistence.update(mappee)", "Persistence.delete(mappee)", "Persistence.flush()". Presto, you can do CUD operations from any code. Then the R is the only Hibernate-specific part, so it's the only thing you need to hide in a DAO.
Quote:
most of our stuff #1/#2 objects can be given directly to the client, but there will be some fat controll classses (e.g. ManglePO) that may need some dto's
Should be no problem. Will be a bit of by-hand coding perhaps but if you only need it in a few places it should be straightforward.
Quote:
thanks for you clarifications. i am a newbie to db and biz illogic so this is very helpful.
You're welcome! Many people here helped me a great deal when I was a Hibernate newbie back in January....
Cheers!
Rob