DAO or Service?

[John Stone]

I'm doing B&S. I see, that some ranchers chose to create a simple interface for clients and gave it a name e.g. ContractorService.

My dilema currently is, whether I should name my interface also in this way, e.g. "ContractorService" or stay with "ContractorDAO".

My reasoning is, that what this interface really does, is providing access to data source (local or remote), where transfer object is Contractor.

I guess, that Service is probably doing something more in real world, but in case of our assignment I don't see difference.

What are the essential differences when I'm calling something Service?

Thank you.

[Gunnar Bastkowski]

Well, in my B&S assingment there is a DB interface which I have to implement using a class called Data.

DB declares some methods like get(recNo), search(...), delete(recNo), ...
all those tasks a usually the concern of a DAO.

In a 3 tier architecture you should now create a layer (the service or business layer) on top of the DAO (DB, Data, ...) which, in very simple cases just delegates to the DAO.
This service usually combines the primitive methods of DAOs to implement the business needs. Checking if a record is available before booking it could be such a task.