views:

91

answers:

5

I'm developing an API for use by one of our vendors to access data in our databases and I need to name my classes. I'm thinking about names such as Retriever, Accessor, and Controller (eg. TimesRetriever, TimesAccessor, TimesController, etc). These classes will provide read only access to data (that I'll be summarizing) in our database. Is there a commonly agreed upon naming convention for what I've described?

+1  A: 

A simple suggestion... why not call it "Database"? That is as clear as you can get. When reading that, you'll know where all the data is coming from right away.

just_wes
A: 

I've most commonly seen people use a "Manager" suffix. I've also seen people use Database as suggested by just_wes. Ex: TimesManager or TimesDatabase or even just Database.

Jeff Peck
-1 for suggesting Manager as a class name!
Adrian
Down mod me if you must, but his question was asking for a term "commonly in use". I agree that using *Manager for everything under the sun can be bad, but it really is a very common term in data access layers.
Jeff Peck
A: 

It's called "Adapter" in LLBLGen Pro

It's called Provider in Delphi DataSnap And Java SDO

I don't think there is a commonly agreed naming convention.

I tend to use Provider or Retriever.

Sake
A: 

"Controller" is used to mean something different. "Accessor" is often used for DB access classes. For this sort of thing, I generally think of it as a Report. In other words, you're not giving full access to to the DB, you're just showing a Report from it based on certain selections (I assume). So, if the output format allows (especially if it's CSV), I would rephrase the whole project as an API to run reports. If that's not possible, I'd go with "Accessor".

Scott Saunders
+2  A: 

Martin Fowler (www.martinfowler.com) is a good source for these types of question; since, you're really talking about design patterns.

My best guess would be the Repository pattern (http://martinfowler.com/eaaCatalog/repository.html).

From the site:

Conceptually, a Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer.

Sounds like what you are trying to do.

SergioL