I've coded a couple of simple systems using Hibernate but regard myself as a relative novice. The essential question to me is how to strategize the mapping hierarchy for flexibility, utility and efficiency. I can't seem to find this addressed anywhere in any real depth (any pointers to good references welcome!).
Issue at hand: I've decided to refactor one of my apps to confine use of domain classes to a DAO, thereby shielding the rest of the app from the domain structure as well as from hibernate concerns such as usability of annotated classes in collections. I will use DTO's to send data outside the DAO rather than domain objs. I find, though, that a simple operation like writing a DAO method to persist a collection of dependent entities is now less simple, because I can't pass in a reference to the an instance of the parent class (since the annotated classes are no longer used outside the DAO). I would only have the parent entity id or a value object, not a domain object reference. I don't want to do an extra get inside the DAO for that. So I could remove the ManyToOne relationship (no longer using it in the child), but it is also useful to have that in place when reading a parent so as to get the dependent entities as well. Can I just create two separate properties inside the child referencing the parent, one an object reference and one an entity reference? I don't believe I've seen that done. This must be a common consideration. If so, what is the common pattern? If not, what is the best practice here?
|