Lazy fetching is extremely useful, since some entities are linked in so many ways that an eager fetch could pull in anything up to and including the entire database!
One thing to be aware of, however, is that Lazy fetches can only be resolved while the entities are attached to the persistence manager. When I code webapps, the database logic detaches the set of objects that it returns to the higher levels of the webapp (for example, the GUI layer). There are several reasons why I prefer doing this, but among the top ones is that it ensures that I don't accidentally zap database data in non-database code. Instead I work with detached data and then when AND IF I want that data to update in the database, I call one of the database logic services that will then convert it to attached data and post the changes to the database server (and, incidentally, ensure that no other process has altered the data behind my back).
To ensure you have exactly what you need in a detached data set, simply force fetches before you detach. For example, if I want to return a working set of an account and its associated funds, but not any other objects that the funds might link to, I'd simply iterate the funds collection that was mapped @ManyToMany and have the iteration look at one of the fields in the funds records (the funds ID field is often a good choice, but any field local to the funds record will do).
An IDE is no substitute for an Intelligent Developer.
If you have a bad day in October, have a slice of banana cream pie. And this tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database