How to keep Hibernate mapping use under control as requirements grow
Posted
by David Plumpton
on Stack Overflow
See other posts from Stack Overflow
or by David Plumpton
Published on 2009-06-23T01:57:16Z
Indexed on
2010/03/13
4:07 UTC
Read the original article
Hit count: 235
I've worked on a number of Java web apps where persistence is via Hibernate, and we start off with some central class (e.g. an insurance application) without any time being spent considering how to break things up into manageable chunks. Over time as features are added we add more mappings (rates, clients, addresses, etc.) and then amount of time spent saving and loading an insurance object and everything it connects to grows. In particular you get close to a go-live date and performance testing with larger amounts of data in each table is starting to demonstrate that it's all too slow.
Obviously there are a number of ways that we could attempt to partition things up, e.g. map only the client classes for the client CRUD screens, etc., which would have been better to get in place earlier rather than trying to work it in at the end of the dev cycle.
I'm just wondering if there are recommendations about ways to handle/mitigate this.
© Stack Overflow or respective owner