Difference between Repository and Service layer

Question

I looked through some related questions but still I don't see much difference between the a repository and a service layer. So given the example I suppose it should look like this , if not please tell me why?

public interface ProductRepository extends CrudRepository<Product, Long>{

    public List<Product> findByName(String name);
    public List<Product> findByPrice(Double price);
}

public interface ProductService {

    public List<Product> findAll();
    public Product findById(Long id);
    public Product save(Product product);
    public void delete(Product product);
    public List<Product> findByName(String name);
    public List<Product> findByPrice(Double price);
}

and the implementation of the ProductService would use the ProductRepository to implement the methods. As I understand from http://docs.spring.io/spring-data/jpa/docs/1.3.0.RELEASE/reference/html/jpa.repositories.html the queries for methods from the repository are auto generated. In my example the methods are repeated in the repository and Service, so please explain what/why needs to be changed?

Gynecium

Answer 1

All your business logic should be in the Service Layer.

Any access to the Database (any storage) should go to the Repository Layer.

Lets take an Example. You have to save an entity(Person). But before saving the Person you want to make sure that the Person's FirstName does not exist already.

So the validation part should go to the business layer.

In the service Layer

PersonRepository repository; 
public Person save(Person p){
   Person p = findByName(p.getName();
   if (p != null){
          return some customException();
   }
   return repository.save(p); 
}

public Person findByName(String name){
     return repository.findByName(name);
}

And in your Repository Layer just concentrate on DB Operation.

You could have done this in Repository Layer it self. Assume you have implemented this in your Repository then your save method always check before saving (some time you may not required to do).

Multiversity

According to your response , I guess I can apply this schema : View<-->Controller( create instance of Model class)<-->Service<--->Repository . – Juggler

yes. the flow is correct view,Controller,Service,Repository . For creating model class in controller and sharing the same instance all the way to Repository depends on how the model class being used. Perfectly fine if the model is not cached any where (session / repository layer) . – Multiversity

Not every "business logic" gives services – Overindulge

Answer 2

Repository Layer gives you additional level of abstraction over data access. Repository layer exposes basic CRUD operations.

Service layer exposes business logic, which uses repository.

You can read a more detailed answer here: https://mcmap.net/q/103156/-difference-between-repository-and-service-layer

Clypeus

Answer 3

A Repository is a data access pattern in which data transfer objects are passed into a repository object that manages CRUD operations. This pattern is useful in situations where the mechanism of your data access may change significantly -- e.g. you expect to have varying data stores like Oracle in one implementation and SQL Server or even HADOOP in another.

A Service Layer is a business logic pattern that is commonly used in SaaS architectures. Using a service layer allows one or more presentation implementations to access your business logic through a common interface. For example if you wanted your website to have an API you would use a service layer to implement common back-end functionality that both the site and the API would consume.

The former should be concerned mostly with data access and the latter with business logic. Neither are mandatory nor must one accompany the other. In simple applications both patterns may be implemented by the same class.

Await

So we need repository only in case of having many databases engines.It has a role of ORM APIs. – Juggler

Answer 4

As far as I know, the Repository is meant for directly accessing the database. This is where direct calls to the stored procedures or whatever your data storage mechanism is will be.

The service layer is the API to your data. There is usually some logic level that you would do hear, or in another layer of abstraction between the service and the repository.

For example, a website would call a method in your service. Your service would call your repository for getting that data, then your service would transform it somehow (build objects, generate dynamic information based on business rules, etc.) then pass that back up to the website.

Haase

Well, so in my example are the rep and service layers correct? And if I have some methods such as say validate(Product p) it should go into the service layer? – Gynecium

It looks okay to me. It is hard to tell, since they are just interfaces, but based on the idea that your repo extends CrudRepo, which I assume has some save/update/delete functions, that appears correct. As for the validation, yes, I would have that being done on the service layer. Usually we have an intermediate business logic that handles things like that. So, for example, service calls business logic which calls repo, but that is dependent on project size. – Haase

Answer 5

It seems that you are using Spring Data in this case where repositories act as DAOs (they define the available database operations and the implementation of these methods is generated by the framework). The service layer should be on top of the repositories, i.e. it accesses data through repositories.

Other answers have not pointed out that you might not need a Service layer: if your implementation is as simple as it seems (only passing entities to the controller without any processing) then a Service layer may be an unnecessary level of abstraction in your application. You should only create a Service layer when it has some purpose.

Ailin

Answer 6

Simply ,I will give a practical example .. like if you have 2 sources of the data , one from local db and the other from a web api for instance. So , the repository should manage that for you , asking for the lacal data ( are you exist ? tes get it from its service, and if Not service please get data from the api …

So we will have 2 services ( water streams ) that get the data to the pool ( repository) .

Foretop