Roman
Roman

Reputation: 66196

Naming conventions for persistence layer: DAO vs Manager vs ...?

DISCLAIMER: I'm almost sure that I've seen the same question before but I can't find it now. If someone finds that question, please, give a link.

I heard at least two opinions on the best name for classes which implements CRUD operations: someone says that DAO is a classical name and everyone knows what it means, but others say that Manager corresponds much better to CRUD functionality.

Are there any unambiguous rules when should I choose one or another (or yet another) name?

Upvotes: 10

Views: 3939

Answers (3)

Jacob Mattison
Jacob Mattison

Reputation: 51062

I definitely don't like Manager; "managing" something could mean (and is used to mean) all kinds of things. If you're afraid people won't know what DAO means, you could always spell it out as "DataAccess", say. But I find DAO to be widely understood.

Another approach is to use the Repository pattern and call your class SuchAndSuchRepository. This isn't necessarily the same thing as a DAO (it may wrap one or more DAOs) but it can provide a clearly named place to go to get your objects -- if I want a Person object, I know to look for the PersonRepository.

Upvotes: 9

crowne
crowne

Reputation: 8534

+1 for DAO.
Manager is vague and could apply to many things other than DAO's.
e.g. swing.DesktopManager, ErrorManager, FontManager, JavaFileManager, XMLEntityManager are some of the 200+ classes currently available in my IDE worskapce, none of which seem to have anything to do with database persistence.

Upvotes: 2

Anatoli
Anatoli

Reputation: 932

I would say Manager, because any "assumptions" can cause some mayhem. And in this case I think you are assuming every body knows DAO.

Upvotes: 0

Related Questions