问题
I'm running into LazyLoading exceptions like the most people who try remoting with an ORM. In most cases switching to eager fetching solves the problem (Lazy Loading / Non atomic queries / Thread safety / n+1 problem ...). But eager fetching has also disadvantages if you are dealing with a really big object graph.
Loading the whole object graph isn't needed in the most use-cases. It feels bad to load more data then needed (or load them from the db and extract the needed subset).
So what alternative ways are there to solve this kind of problem (at runtime)?
I've seen:
- Inject a data access dependency into domain object and let the object decide either to load lazy or eager: Feels bad! The domain layer should be independent from any service. Domain injection is also an expensive operation. The domain should be data access ignorant and should be used with or without data access.
- Fetch everything lazy except of use-cases which require more data: Seems better for performance but this way forces many client=>server / database roundtrips. The initialisation of the lazy fields can also suffer pain (tried with JPA). This way doesn't feel generic and is subject of the same lazy restrictions mentioned above.
- Encapsulate persistence in Lazy class: More complexity, no best practice for interoperation with ORM. Bloating services layer (so much "hand written" code feels bad).
- Use full projections for every use-case: We'll end up in SQL and drop the benefit of an ORM.
- A DTO / Virtual Proxy layer enforces more complexity and makes code harder to maintain (Wormhole antipattern >> Bloat).
I thought a lot about another way. Maybe generic projection white./black listning is a solution.
Idea (blacklist): Define an classname list with the boundaries for a fetching operation. If a property matches and it's lazy, remove the lazy (CGLIB) proxy and fill the value with null. Else, simple prevent from fetching (and leave value at null). So we can set clear boundaries in our DAOs.
Example: ProductDao.findByName("Soap",Boundaries.BLACKLIST,"Category, Discount")
the two last parameters can also been bound into a Boundaries object.
Idea (whitelist): Like blacklist, but you must declare properties with should be loaded in a whitelist.
What do you think about such a solution? (Possible problems, restrictions, advantages ...) How should I write this in java? Maybe via AOP to match DAO methods (because I'm able to modifiy cglib proxy behaviour there)?
回答1:
You can get rid of all collections whatsoever and use
NamedQueriesinstead. We used this approach in one project (EJB + Swing), and it worked pretty well - thus you determine exact data to be fetched. NamedQueries are normal queries, imagine them as PreparedStatement-s. The idea is not to create/retreive/update/delete single objects with queries. The idea is that you fetch your Collections with queries. For example, instead of mapping a @ManyToMany List, define a NamedQuery that fetches that list. Thus you can fetch the collection data separately, and only whenever you need it, not automatically.Use a custom Proxy (using CGLIB) for transferred objects - whenever a collection is referenced (via its getter), attempt retreival, and catch any
LazyInitializationExceptionand make a call to the server tier for the data requested.Just as the previous one, but make proxies only of the collections, in the way Hibernate proxies them when lazy initialization is needed.
Also, take a look at the Value List Handler pattern - might be useful.
(You can also use hibernate.max_fetch_depth (if using Hibernate) with a combination of the above, if it is suitable for your case.)
回答2:
Nowadays (2013), it is possible to keep lazy-loading if you remote your service with GraniteDS.
That should properly serialize your JPA or Hibernate entities by not initializing lazy relations and keeping the lazy-state for the client. If you access those relations on the client, it will fetch them transparently in the background.
Moreover, GraniteDS seems to be able to do inverse lazy loading which means that when you send modified objects back to the server, it will not send unchanged entities back thus making the necessary server communication very efficient.
I am not a GraniteDS expert (yet) but it seems to be able to integrate with JEE6 and Spring service layers and works with all of the most important JPA providers.
Naturally, you will need to hide the GraniteDS based remoting behind a service interface for maximizing transparent behaviour but that can be easily be done if the client also uses Spring (so you inject the service according to the needs of the environment).
回答3:
Although it takes a bit of work and for JAX-WS/JAXB requires recent versions of those libraries, this is a very elegant solution: create a marshaller that can test for whether objects / collections have been initialized.
As described here: https://forum.hibernate.org/viewtopic.php?f=1&t=998896
来源：https://stackoverflow.com/questions/1778578/lazy-eager-loading-strategies-in-remoting-cases-jpa