Difference between repository and service?

Question

What's the difference between a repository and a service? I don't seem to grasp it.

I'm talking about data access through a data access layer, typically with linq to sql.

Very often i see repositories with simple CRUD methods, and services with more business-specific methods.

We can take this blog post as an example. If you look at the interfaces at the bottom (images), he has two repositories and two services. How does one know what to put where?

As I said, repositories seems to be more for CRUD-like operations and Services more business oriented.

Pfeffer

Can you calarify? In what context? Like most words, the context these words are being used in helps to define the meaning. – Estienne

Note: I'n not talking about web services or something here. I'm talking about data access through a data layer. – Pfeffer

#22963852 – Atypical

Answer 1

A Repository is essentially a facade for persistence that uses Collection style semantics (Add, Update, Remove) to supply access to data/objects. It is a way of decoupling the way you store data/objects from the rest of the application.

A service supplies coordination or other "services" that are required to operate your application. They are very different in that Services don't typically know how to access data from persistence, and repositories typically only access data/objects for any services you may have.

Supercharge

I would say that a Repository is a type of service that is used for data access. – Celadon

That's a fine definition in the sense that almost everything we write is a "service" at some level, but it loses the basic intent that a repository is supposed to be a collection of objects. – Supercharge

If you grok unit testing it might be clearer to think of repositories as the minimal abstraction to minimize the mocking needed to avoid database. – Autocatalysis

repository = collection from backbone.js or repository = service from angular? – Euphemie

Answer 2

The repository is where the data is stored. The service is what manipulates the data.

In a real-world situation comparison, if your money is stored in a vault in a bank, the vault is the repository. The teller that deposits, withdraws, etc is the service.

Estienne

mm. so if the bank decides to get rid of the vault, and put money under matrasses, the teller will still interact with you as before, without you having to know about the change in the repository layer. – Specific

I suspect the customer would want to know about that implementation, @Specific – Dorado

But the repository also contain methods that manipulate the data, for example methods like Add and Update. – Spendthrift

@Specific Yes. This is actually one of the main advantages of using the repository pattern. You should be able to change the actual implementation of the repository interfaces without changing anything on the service. This has huge benefits for unit testing and making your code loosely coupled. – Acrobatics

@Specific This sounds more like an interactor or a command/use-case in my opinion, so what's the difference between interactors and services? – Lyall

To my mind this answer is wrong. The repository provides CRUD operations on a data context (and therefore manipulates it) while the service executes operations on top of the CRUD operations e.g. a user service would create a user by using a user repository and might send it to another service after creation. – Loopy

Answer 3

I would say as a first try, in the general sense (until you give more context if you have one):

• a repository is where you place some global objects, to be used later.
• a service is a business logic code, made explicit (and ideally separated from the Presentation layer, and database layer ?)

Waive

Would it be okay to do the following then: My repository has all my complex database calls, then in my service i inject the repository as a dependency. Now I have easily testable code and separated my concerns, because my service does not know how the DB calls are done, but merely calls the functions of the repository that does. Therefore business logic and data access are separated. Would this be a viable approach? – Provolone

If all the logic is written in services, then the controller will only call the service? – Jovitajovitah

Answer 4

Take for instance in a MVC application.The Controller gives instruction to the Service and the service talks to the Repository to do some CRUD to the data in database.

This is done using DI(Dependency Injection:this is like a child telling the father to give him money but is not bothered about how the money is gotten,so the methods of getting the money was abstracted from the child's knowledge)

Repository communicate with the database either using raw SQL query Or Via ORM(e.g Eloquent,Sequelize,Gorm,Hibernate e.t.c)

Service calls one or more methods in the repository to get a specific result.(in the service you can call a sample method in the repository called findOne() and then base on the result you can call updateOne())

Godfry

Answer 5

A repository handles the data access and the service calls into it after performing any business logic needed.

@David 's answer definitely helped me but I would like to skew his approach a bit.

The Bank Metaphor: The bank holds your money in a vault, the vault is a database. The teller can deposit or withdraw from the vault, the teller is the repository. The customer is the one who asks the teller to deposit or withdraw, the customer is the service.

You can even take it further and say your employer (whoever writes your check) is the controller :D

The controller hands you your check -> you validate to make sure everything is correct before giving it to the teller -> the teller deposits.

So by thinking of it this way you can see the repository only cares about doing database operations or transactions, many services/customers can go to the same repository/teller.

Chapin

"A repository handles the data access and the service calls into it after performing any business logic needed." Clear and concise, thanks. – Gyrostat