I'm having a bit of trouble organizing DAO methods and I was wondering if there was anyone that could help me out. My main problem is avoiding similar queries and avoiding the duplication, or having to provide queries that only initialize different things depending on who is calling the code.

My first problem is that I often have a lot of methods that both get a list of objects and I have an almost similar query that counts the number of items that this query would return (for paging purposes). So my interface looks like this:

businessObject.findAllByThisAndThat( ... )

businessObject.countAllByThisAndThat( ... )

This is not so bad, although the reuse of queries is a little annoying. Any good approaches for minimizing query duplication?

My second problem, which is probably bigger, is that I have different services that require different levels of initialization, and I'm not really sure what's a good way to deal with all the needs. Some clients simply want the object itself, with no dependancies. Others just want the one-to-many collections initialized, others want the many-to-one dependancie (however, these are also on a fine-grained basis) and others just might want the entire thing initialized. What is the best way to manage this?

Right now, I'm basically appending the use-case at the end of the method, which doesn't sound like a very good idea but I don't know a good way around it.

findMyObjectForMenuGeneration

findMyObjectForEditing

findMyObjectForListing

:/

Any help would be appreciated.

You can do findByCriteria(Criteria) and manage the complexity in your method.

2 solution for the second problem :
1. do what you did for very different graph fill
2. do the same query and use Hibernate.initialize to complete the needs OR fill it every time. You'll chose the best way by using the magic 80%-20% rule
3. think of first and second level cache. If your entity is likely beeing loaded by a previous process, you can deoptimize you query since the dependent objects are already loaded.

Thanks for the response. Part of my problem is that I don't want outside code to bother initializing the object. They shouldn't know about Hibernate at all. Thus, it does need to be shielded from them but at the same time, I worry about performance a great deal (one thing that I always have to worry about is performance upfront because it's always been a problem for some reason with postgres+hibernate).

I thought that maybe I could have a boolean interface instead. Perhaps something like this:

findAdministrator( Long administrator Id, boolean loadUsers, loadOther dependancy )

Maybe something like this gives the ultimate flexibility to clients. However, if I have another way of finding administrators, such as findAdministratorByCode, the loading logic that tests the boolean parameters needs to be refactored into helper methods.

I just wish clients didn't have to worry so much about it.

Is there any good tips for improving performance with hibernate+postgres other than trying to optimize how much data Hibernate loads? I am using the transaction-level cache on sets of objects that don't change all that much. I'm not caching things that would consume too much memory (like search results from a pool of millions of objects for example - that's a waste of caching when it's used only once, not that I'd display all million in the first place, but you know what I mean).

I just find that I always run into performance problems, over and over. Everytime I think I learned something new on how to make my stuff better and design it that way from the start, another curve-ball happens and it seems I have to learn something else :) I wish I could learn from the masters so I'd stop making mistakes :/

Thanks for your timely response,
Ken

You don't necessary have to cache queries.
You can cache common objects with an appropriate cache algorithm.


Have a look at Hibernate in Action, it helps *a lot*, especially in your learning state

I can't remember someone complaining specifically with hibernate+postgres perf issues.