I planning to split my systems into front-end and back-end. Currently my application directly communicates with database, but I want to create a Spring Web service to do it instead. My problem lies with using Hibernate to map my objects to database tables.
I need my front end program to have persistant up-to-date interaction with the database. This again means I have to write a lot of web service endpoints to handle all the queries and updates. This again makes it Hibernate mapping pointless, since I’m not gaining anything.
My question is: is there a proven and reasonable way to pass (via SOAP if possible) hibernate mapped objects over to front-end and later commit changes done to these objects?
In short: no.
Detaching and re-attaching hibernate-managed objects in different applications, like you are thinking of, will lead to all kinds of problems that you want to avoid, such as concurrency and locking issues, after you’ve dealt with all the LazyLoadingExceptions. It will be a pain in the b***.
The road you’re heading into finally leads to an architecture that adds an extra layer of indirection with Data Objects being transferred between business service and clients of those business services. Only your business service will be able to talk to the database directly. Obviously this time-consuming, and must be avoided if possible. That’s why I asked you to explain the problem you’re trying to solve.