Thanks for the feedback!
Yes, I’ve been looking at Spring Data. If I see enough confirmation from the community that it is solid, then perhaps I’ll refactor ExpressUI to use it.
However, one the best features of ExpressUI is that it handles the problem of combining paging with fetch joins. Normally, if you use these features together in Hibernate, Hibernate fetches the entire result set and pages through it in memory. You get a warning in the log that says “applying in memory.” This means that using paging and fetch joins doesn’t scale for large result sets, as it is not feasible to suck millions of records into memory.
My framework works around this problem using a pattern where the query is divided into three parts: count, fetch of IDs and fetch joined data based on IDs. I’m not sure how Spring Data deals with this problem. I can’t find any posts that confirm or deny that it handles this problem gracefully.
The paging-fetch-join problem is the same reason why I avoid using any of the JPA add-ons. I’m not sure if or how they might handle this problem. I’d be curious to do know if others on this forum have been able to page through million-record result sets using complex relational fetch joins to avoid the N+1 select problem.
BTW, another thing that is a little cheesy about Spring Data is generating queries from method names. IMO, the coolness factor of that approach doesn’t outweigh the possibility that it will confuse developers and my IDE, which is better at parsing in-line queries. Also, it seems like that approach is only suitable for simplistic queries. Anyway, I like the overall concept of Spring Data. So, I’m keeping my eye on it!
Juan