What's a good alternative, general name to the HibernateUtil class?

Question

Hi, I have a HibernateUtil class which is the standard by the book (Hibernate in action) class.
It gets a session, flushes and closes it. begins,commits and rollbacks transactions and build the sessionFactory.
Currently, by mistake, this is called HibernateSessionFactory in our package.
I want to refactor it to a more appropriate name but the name HibernateUtil bothers me as I'd like to choose a more general name something like PersistentManagerUtil.
Is there a good java convention or consensus about such a name?

EDIT The reason I want to make it more general is that I want to minimilize the "Exposure" to the specific ORM implementation. Most of the public methods of the class have void as a return type so they do not return Hibernate classes/interfaces. The only exception to this is the getSession which returns an org.hibernate.Session. The reason I was thinking this direction is because I want to switch over to JPA and have hibernate as the implementation and so have a bit more freedom. Why not change it to EntityManagerUtil? As in hibernate's docs they say EntityManager is equivelant to Session and that EntityManagerFactory is equivelant to HibernateSessionFactory.

Thanks in advance,
Ittai

Answer 1

Don't make it more general, unless the class can really do anything other than talk to Hibernate. It is using Hibernate classes and interfaces in its public API, right? As long as it is Hibernate-specific (in both interface and implementation), it would be good to let everyone know about it in its name.

HibernateUtil sounds good.

Most of the public methods of the class have void as a return type so they do not return Hibernate classes/interfaces. The only exception to this is the getSession which returns an org.hibernate.Session. The reason I was thinking this direction is because I want to switch over to JPA and have hibernate as the implementation and so have a bit more freedom.

Well, you can change the name to JpaUtil once you got rid of getSession.

Answer 2

Your class is Hibernate specific, so it's good to have that in its name.

Does it create Sessions, or get them from elsewhere? If it creates them, Factory is also a good name. If not, it sounds like it manages Sessions so how about 'HibernateSessionManager'?

Your name 'HibernateUtil' is if anything too general. I always take 'util' packages and classes as a code smell; they usually pop up because the designer had a bunch of stuff he/she did not know where to put. Your class is not like that, it apparently focuses on the management of hibernate sessions.

As to your question about existing conventions or consensus about naming. There are some guidelines (but you probably already know them):

• methods should reflect an action on the class they reside in and if possible have a logical argument order. Example: ChessBoard.swapPlayers(Player a, Player b)
• for methods returning a boolean use a predicate like isActivated or hasPlayers
• another style is method chaining, where the chained methods read a bit like an english sentence: verify(mockedList, atLeastOnce()).add("three times"); (mockito)
• The JavaDoc on methods should describe the action, for example: swaps players A and B so that they continue the game with each others' pieces".
• classes should represent a 'thing' with a clear responsibility. Examples: StringBuilder, Customer, PdfServlet. If a secondary responsibility creeps into a class, this usually means it should be refactored into two collaborating classes.
• JavaDoc on classes should describe the 'thing' and its main responsibility. Behavior should be described insofar it is valuable information for the client. Implementation details should usually not be described in the public JavaDoc.

Oh yes, and I happen to think naming is extremely important for good software design. But I guess that was already clear (-:

EDIT: in response to your edit. As long as it returns a Hibernate type, it is still Hibernate specific. If you manage to totally abstract away from Hibernate, towards JPA, then it would make sense to name it JpaSessionManager (or JPASessionManager if you prefer) for example. But this would require to return a JPA-only session object.