I am developing an API to be used by our suppliers to gain access to data within our databases and I have to title my classes. I am considering names for example Retriever, Accessor, and Controller (eg. TimesRetriever, TimesAccessor, TimesController, etc). These classes will give you read only use of data (that I'm going to be outlining) within our database. It is possible to generally decided naming convention for which I have referred to?
Martin Fowler (www.martinfowler.com) is a great source for these kinds of question since, you are really speaking about design designs.
My best guess will be the Repository pattern (http://martinfowler.com/eaaCatalog/repository.html).
In the site:
Conceptually, a Repository encapsulates the group of objects endured inside a data store and also the procedures carried out them over, supplying a far more object-oriented view from the persistence layer.
Seems like what you're attempting to do.
An easy suggestion... why don't you refer to it as "Database"? That's as obvious as possible. When reading through that, you know where all of the information is originating from immediately.
I have most generally seen people make use of a "Manager" suffix. I have also seen people use Database as recommended just by_wes. Ex: TimesManager or TimesDatabase as well as just Database.
It's known as "Adapter" in LLBLGen Professional
It's known as Provider in Delphi DataSnap And Java SDO
I do not think there's a generally agreed naming convention.
I am inclined to use Provider or Retriever.
"Controller" can be used to mean different things. "Accessor" is frequently employed for DB access classes. With this kind of factor, I generally think about it as being a study. Quite simply, you are not giving full use of towards the DB, you are just showing a study from this according to certain choices (I suppose). So, when the output format enables (particularly if it's CSV), I'd rephrase the entire project being an API to operate reviews. If that is difficult, I'd opt for "Accessor".