스프링부트 기초 / Repository & Service

Repository

객체를 작성했다면 그 객체에 알맞게 작성, 조회, 수정, 삭제 등을 하는 계층이 필요하다.

이러한 것들을 위한 로직이 모여있는 계층이 Repository이다.

 

위 리포지토리에선 엔티티매니저를 이용해 객체를 persist 하고 찾는 로직이 작성되어 있다.

@PersistenceContext 는 스프링 컨테이너에 등록된 빈을 찾아 주입해준다.

최신 스프링 부트에선 @Autowired로도 가능하다고 한다.

 

그 아래 findByName 메서드는 매개변수로 name을 받는다.

name이 일치한 member를 찾아 반환해주는 쿼리문이 담겨있는데 파라미터가 필요한 쿼리문의 경우 사진과 같이 작성을 해줘야 한다.

필드명 =: 매개변수

 

그 후 바로 getResultList를 호출해 받아오는게 아니라 그 전에 매개변수로 받은 데이터를 해당 쿼리문에 포함시켜 파라미터 바인딩을 한 뒤 결과를 받아온다.

 

서비스 계층

서비스 계층은 다양한 비즈니스 로직이 수행되는 계층이다.

여러 요청이 들어오면 해당 요청에 필요한 비즈니스 로직을 서비스 계층에서 수행시켜 그 결과를 Controller 계층에 전달하고 결과물은 Client에게 전달한다.

 

서비스 계층에서도 객체의 등록, 수정, 삭제, 조회 등은 리포지토리에 위임한다.

 

 

Item 관련 Repository & Service

Item의 경우 몇 비즈니스 로직이 엔티티 클래스 내에 작성되어 있다. 이유는 다음과 같다.

비즈니스 로직을 엔티티에 넣어주면 응집도가 높다. (해당 필드를 직접 건드릴 경우)

ItemRepository

save 메서드를 보면 매개변수로 받은 객체의 id값을 확인한다.

그 이유는 item의 getId가 null이라면 새로운 객체이기 때문이다.

만약 수정을 위한 객체가 매개변수로 왔다면 이미 db와 영속성 컨텍스트를 거쳐 pk값이 존재할 것이다. 

=> 따라서 pk가 null이면 새로 등록하는 객체이다.

=> persist가 되기 전엔 아직 pk가 존재하지 않는다.

null이 아닌 경우 merge 처리를 하는데 merge는 권장되는 수정 방식이 아니기 때문에 추후에 수정한다.

서비스 계층

 

개발 패턴의 차이

• 엔티티에 핵심 비즈니스 로직을 몰아넣는 방법을 도메인 모델 패턴이라고 한다.
  => 서비스 계층은 위임만 함
• 서비스 계층에서 비즈니스 로직을 처리하는 것을 트랜잭셔널 스크립트 패턴이라고 한다.

따라서 위 Item의 개발 패턴 방식은 도메인 모델 패턴이다.