This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
No announcement yet.
How Common to Spring Manage Beans Created By Hibernate?Page Title Module
There is a slight inconsistency with how Hibernate might wire a bean's ID and how this new interceptor is doing it.
The interceptor will use BeanWrapper.setPropertyValue to set the ID. This will not work if the bean has only a getter for the ID (and only field access for the ID). If no setter exists, then a NotWritablePropertyException is thrown.
Hibernate, on the other hand, is able to use field access to set properties of a bean.
I wonder if the interceptor should first try setPropertyValue, and if it fails, to try setting the field directly? We removed our setId() method to make it more clear users aren't able to set this. We'll set it to private for now, but if we're able to set the ID via its field, that would be even better.
Re: How Common to Spring Manage Beans Created By Hibernate?
Originally posted by sethladd
We've heard time and time again to "put business logic inside your business objects". Most of the time, full business logic requires dependencies to be injected in my business object. The business objects themselves (Business, Account, etc) are managed by Hibernate. Their dependencies are/should be managed by Spring.
How common is this? If my business object is something that comes from the database, but requires external dependencies, then Spring must create and wire up my object.
This seems fair and good, but I haven't seen many examples of this usage. It makes me wonder if my business domain objects (those that come from the database) should ever rely on external dependencies.
My gut says yes: keep business logic in business object. Note: this does not mean DAO type actions.
Of course, I could keep the business objects free from external dependencies, but then their ability to do work is greatly lessened.
Thoughts? Comments? War stories?
Thanks very much!
If you use dependency injection (Spring beans) how would you like to solve the issue that a persistent object lives only as long as the transaction lives?
If you create a Spring bean and it references a persistent object you'll get an exception if the next transaction tries to access the referenced object. This is because the object is only valid for the transaction it was loaded. After commit/rollback the association with the DB is lost.
I think you are talking about how once you close the session, you aren't able to traverse lazy loaded relationships. That is true. It's a good practice to load up all relationships needed for the use case before the session is closed. Then, when that object "goes out into the wild", you have loaded everything.
We've been DI'ing our Hibernate objects for some time with great success. I think it was a key missing ingredient for a true OO system.
I see that the lates code in the sandbox (at least that I could find) related to this has not been updated in over a year and never made it into the actual framework. Currently, using Hibernate 3 without Hibernate 2 in the classpath breaks the sandbox code, as it relies on Hibernate 2 Interceptor (net.sf) syntax. Not intending to re-open old wounds, but what's the current thinking on how
best to address this type of functionality?
While I like aspectj, on large development teams it isn't always possible to force aspectj weaving on everyone. In addition, the documentation in 6.8.1 does reference DependencyInjectionInterceptorFactoryBean, but when I look at both the svn and cvs repository here, I don't see the bean.
I'm going to investigate further the blog post referenced above to see if I can figure out a decent, non-aspectj solution to this problem, outside of apparently DependencyInjectionInterceptorFactoryBean, unless I can find (or am told about) an up to date version somewhere.