[JPA] OSIV 란?

 

 

 

 

 

 

 

 

스프링에서 JPA를 사용하게 되면 스프링 컨테이너가 트랜잭션과 영속성 컨텍스트를 관리해주므로 애플리케이션을 손쉽게 개발할 수 있습니다.

 

당연하게도 이러한 JPA의 내부 동작원리를 모르고 사용한다면 여러 문제가 발생했을 때 해결하기 어렵습니다.

 

 

이번 글을 통해 JPA가 동작하는 내부 방식을 이해하고, 애플리케이션을 개발할 때 발생할 수 있는 다양한 문제점과 해결 방안을 알아보도록 하겠습니다.

 

 

 

 

 

 

 

 

 

 

트랜잭션 범위의 영속성 컨텍스트

스프링 컨테이너의 기본 전략은 '트랜잭션 범위의 영속성 컨텍스트' 입니다.

스프링에서 JPA를 사용하게 되면, 스프링 컨테이너가 제공하는 전략을 따라야 합니다.

 

스프링 컨테이너는 JPA의 영속성 컨텍스트를 지원할 때, 기본 전략으로 트랜잭션 범위의 영속성 컨텍스트를 사용합니다.

 

 

트랜잭션의 범위와 영속성 컨텍스트의 생존 범위를 맞추는 전략으로,

트랜잭션이 시작하는 순간 영속성 컨텍스트도 생성되고 트랜잭션이 끝나는 순간에 영속성 컨텍스트가 종료됩니다.

 

 

트랜잭션 범위의 영속성 컨텍스트

 

 

 

보통 우리는 비즈니스 로직을 시작하는 Business Layer(혹은 Service Layer)에 @Transaction 어노테이션을 사용하여 트랜잭션을 시작합니다.

 

@Transaction 어노테이션이 있으면 호출한 메소드를 실행하기 직전에 스프링의 트랜잭션 AOP가 먼저 동작합니다.

 

 

 

 

코드를 통해 살펴보도록 하겠습니다.

@Transactional
public class MemberService {
	//CODE
    
    public Member join(Member member){
    	//member를 persist하는 코드 & 이런저런 처리 로직
        return member;
    }
}

@Controller
public class MemberController {
    //CODE
    
    @PostMapping("/~~")
    public void signUp(@RequestBody MemberDto memberDto){
    	Member member = memberService.join(memberDto.toEntity); //호출 시 AOP가 먼저 작동하여 트랜잭션 시작
    }
}

 

위 코드에서 signUp()을 호출하는 경우, join()을 호출하기 전에 스프링의 트랜잭션 AOP가 먼저 작동하여 트랜잭션을 시작합니다.

 

트랜잭션의 대상 메소드(join())가 정상 종료되면 트랜잭션을 커밋하면서 종료합니다.

 

트랜잭션을 커밋하게 되면 JPA는 영속성 컨텍스트를 플러시해서 변경 내용을 데이터베이스에 반영한 후에, 데이터베이스 트랜잭션을 커밋합니다.

 

만약 예외가 발생한다면 트랜잭션을 롤백하고 종료하는데 이 경우에는 플러시를 호출하지 않습니다.

(체크드 예외와 언체크드 예외에 따라 다르지만, 넘어가도록 하겠습니다.)

 

 

 

signUp()에서 join()을 호출한 뒤 member를 반환받았습니다.

 

현재 이 member는 영속성 컨텍스트가 끝났기 때문에 준영속 상태입니다.

이를 인지하고 다음으로 넘어가겠습니다.

member는 반환되어 준영속 상태입니다.

 

 

 

 

 

 

 

 

 

 

 

 

같은 트랜잭션을 사용하는 경우

트랜잭션이 같으면, 같은 영속성 컨텍스트를 사용합니다.

트랜잭션 범위의 영속성 컨텍스트 전략은 다양한 위치에서 엔티티 매니저를 주입받아 사용하더라도,

동일한 트랜잭션 내에서는 항상 같은 영속성 컨텍스트를 사용하게끔 구현되어 있습니다.

 

 

 

예시를 들어보겠습니다.

@Repository
class Repo1 {
    @PersistenceContext EntityManager em;
    
    public void logic1(){
    	em.xxx(); // Repo1의 영속성 컨텍스트 접근
    }
}


@Repository
class Repo2 {
    @PersistenceContext EntityManager em;
    
    public void logic2(){
    	em.xxx(); // Repo2의 영속성 컨텍스트 접근
    }
}

 

 

 

위와 같은 상황에서 아래 코드의 logic()을 실행하는 상황을 살펴보겠습니다.

@Service
class MainService{
    @Autowired Repo1 repo1;
    @Autowired Repo2 repo2;
    
    @Transctional
    public void logic(){
    	repo1.logic1();
        repo2.logic2(); 
    }
}

 

 

repo1과 repo2의 엔티티 매니저는 다르지만, 같은 영속성 컨텍스트를 사용합니다.

동일한 트랜잭션에서는 항상 같은 영속성 컨텍스트를 사용하기 때문입니다.

 

 

그리고 해당 영속성 컨텍스트는 트랜잭션과 생명주기가 동일합니다.

 

 

 

 

 

 

 

 

 

다른 트랜잭션을 사용하는 경우

트랜잭션이 다르면, 다른 영속성 컨텍스트를 사용합니다.

 

 

 

 

 

 

 

 

 

 

 

트랜잭션 범위의 영속성 컨텍스트 전략 정리

동일한 트랜잭션이라면 동일한 영속성 컨텍스트를 사용합니다.

트랜잭션과 영속성 컨텍스트의 생명주기가 동일합니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

준영속 상태와 지연 로딩

스프링 컨테이너의 기본 전략은 트랜잭션 범위의 영속성 컨텍스트 전략입니다.

 

그리고 트랜잭션은 보통 서비스 계층에서 시작하므로 서비스 계층이 시작되는 순간 트랜잭션이 생성되고,

서비스 계층이 끝나는 시점에 트랜잭션이 종료되면서 영속성 컨텍스트도 함께 종료됩니다.

 

서비스 계층에서 조회한 엔티티는 서비스와 리포지토리 계층에서는 영속성 컨텍스트에 관리되지만,

컨트롤러나 뷰 같은 프리젠테이션 계층에서는 준영속 상태(영속성 컨텍스트에 관리되지 않는)가 됩니다.

 

 

그림으로 표현한 영속상태 범위

 

 

 

 

 

위에서 member를 반환하는 예시로 돌아가 보도록 하겠습니다.

MemberController에 반환된 member는 현재 준영속 상태입니다.

member는 반환되어 준영속 상태입니다.

 

트랜잭션 범위의 영속성 컨텍스트 전략에서는 트랜잭션이 끝나면 영속성 컨텍스트가 종료됩니다.

따라서 프리젠테이션 계층에서는 트랜잭션이 종료되었기 때문에 member는 준영속 상태인 것입니다.

 

 

준영속 상태는 영속 상태가 아니기 때문에 영속성 컨텍스트에서 제공하는 기능을 사용하지 못합니다.

당연하게도 영속성 컨텍스트가 제공하는 지연로딩 기능도 사용하지 못합니다.

 

 

아래는 아까 전 signUp() 예시에서 연관된 Team의 name을 조회하는 코드를 작성한 것입니다.

@Controller
public class MemberController {
	
    //CODE
    
    @PostMapping("/~~")
    public void signUp(@RequestBody MemberDto memberDto){
    
    	Member member = memberService.join(memberDto.toEntity); 
        //현재 member는 준영속 상태
        
    	Team team = memger.getTeam();
        team.getName(); //지연 로딩 시 예외 발생
    }

}

 

member는 준영속 상태이기 때문에 지연 로딩시 예외가 발생합니다.

 

 

 

 

 

 

 

준영속 상태와 지연 로딩

준영속 상태의 가장 골치 아픈 문제점은 지연 로딩 기능을 사용할 수 없다는 것입니다.

 

예를 들어 뷰를 렌더링하는 경우, 조회한 엔티티와 연관된 엔티티도 함께 사용해야 합니다.

그런데 연관된 엔티티를 지연 로딩으로 설정하여 프록시 객체를 조회했다고 가정하겠습니다.

(위의 예시에서는 Team을 지연 로딩으로 설정하였고, Team 객체를 프록시 객체로 조회한 상황입니다.)

 

프록시 객체는 초기화되지 않은 상태로 프리젠테이션 계층에 반환된 상태입니다.

이후 실제 데이터를 불러오려고 초기화를 시도할 경우 준영속 상태이기 때문에 지연 로딩이 작동하지 않아 예외가 발생합니다.

 

 

 

이제 이를 해결하는 방법에 대해서 알아보겠습니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

준영속 상태의 지연 로딩 해결방법

• 뷰에서 필요한 엔티티를 서비스 계층에서 미리 로딩해두는 방법
• OSIV를 사용해서 엔티티를 프리젠테이션 계층까지 영속 상태로 유지하는 방법

 

 

 

 

 

 

뷰가 필요한 엔티티를 미리 로딩해두는 방법

• JPQL 페치 조인 사용
• 강제로 초기화
• FACADE 계층 추가

 

 

 

 

 

JPQL 페치 조인 사용

페치 조인은 당연하게 알 것이라 생각하고 넘어가겠습니다.

모른다면 저의 다른 글 들, 혹은 다른 자료들을 참고하여 공부하는 것을 추천합니다.

 

 

페치 조인의 단점은 화면에 맞춘 리포지토리 메소드가 증가할 수 있다는 것입니다.

이는 프리젠테이션 계층이 데이터 접근 계층을 침범해버리는 결과를 초래합니다.

 

이를 해결하는 간단한 방법은 다음과 같습니다.

화면 A를 위한 Member만 조회하는 memberRepo.findMember() 메소드
화면 B를 위한 Member와 Team을 같이 조회하는 memberRepo.findMemberWithTeam() 메소드

 

위 상황은 프리젠테이션 계층이 논리적으로 memberRepo를 침범하고 있는 상황입니다.

이를 해결하기 위해 memberRepo.findMember() 메소드 하나만을 사용한 후, 해당 메서드에서 fetch join을 사용하여 Team까지 한번에 조회하는 것입니다.

 

이렇게 하면 분명 A에서는 Team이 필요 없기 때문에 약간의 로딩 시간이 더 길어질 수는 있습니다.

그러나 그 영향력은 미비하며 무분별한 데이터 최적화로 프리젠테이션 계층과 데이터 접근 계층 간의 의존관계가 급격하게 증가하는 것보다는 적절한 선에서 타협점을 찾는 것이 합리적입니다.

 

 

 

 

 

 

 

 

 

강제로 초기화

강제로 초기화는 영속성 컨텍스트가 살아있을 때, 프리젠테이션 계층이 필요한 엔티티를 강제로 초기화하여 반환하는 방법입니다.

 

위의 예시에서는 아래와 같이 team 프록시를 강제로 초기화 할 수 있습니다.

public Member join(Member member){
    	//member를 persist하는 코드 & 이런저런 처리 로직
       	member.getTeam().getName(); //강제로 초기화
        return member;
}

 

그러나 이 역시 프레젠테이션 계층이 Service 계층을 침범해버리는 상황입니다.

 

이를 해결하기 위한 방법으로 FACADE(퍼사드) 패턴을 도입할 수 있습니다.

 

 

 

 

 

 

 

 

 

 

FACADE 계층 추가

FACADE 계층은 뷰를 위한 프록시 초기화를 담당할 것입니다.

Facade 계층도 영속속 컨텍스트의 생존 범위 안에 존재합니다.

 

 

 

프록시를 초기화하려면 영속성 컨텍스트가 필요하기 때문에, 트랜잭션은 FACADE에서 시작됩니다.

 

 

 

 

FACADE 계층은 다음과 같은 역할을 수행합니다.

• 프리젠테이션 계층과 도메인 모델 계층 간의 논리적 의존성을 분리합니다.
• 프리젠테이션 계층에서 필요한 프록시의 객체를 초기화해줍니다.
• 서비스 계층을 호출하여 비즈니스 로직을 실행합니다.
• 리포지토리를 직접 호출해서 뷰가 요구하는 엔티티를 찾을 수도 있습니다.

 

 

 

 

 

 

 

FACADE를 도입하는 예제를 살펴보겠습니다.

class MemberFacade {
	
    @Autowired MemberSerivce memberSerivce;
    
    public Member signUp(Member member){
    	Member findMember = memberService.join(member);
        findMember.getTeam().getName();
        return findMember;
    }

}

 

이제 컨트롤러에서 MemberService 대신 MemberFacade의 signUp()을 호출해주면 됩니다.

 

 

FACADE 계층을 사용해서 서비스 계층과 프레젠테이션 계층의 논리적 의존성을 분리하였습니다.

이는 이론적으로는 매우 훌륭하나 실용적인 관점으로 볼 때, 중간에 계층이 하나 더 추가되기 때문에 더 많은 코드를 작성해야 합니다.

 

 

 

 

 

 

 

 

지금까지 뷰가 필요한 엔티티를 미리 로딩해두는 방법에 대해서 살펴보았습니다.

위 방법들은 상당히 번거롭고, 이런저런 문제점이 많이 생길 수 있습니다.

 

 

이 모든 문제의 원인은 엔티티가 프리젠테이션 계층에서 준영속 상태이기 때문에 발생하는 문제입니다.

 

영속성 컨텍스트를 뷰까지 살아있게 만들어줄 방법이 있다면 뷰에서도 지연 로딩을 사용할 수 있을 것이고, 위의 문제점들을 쉽게 해결할 수 있을 것입니다.

 

 

영속성 컨텍스트를 뷰까지 살아있게 만들어줄 방법. 그것이 바로 OSIV입니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

OSIV (Open Session In View)

영속성 컨텍스트를 뷰까지 열어두겠다는 의미입니다.

사실은 OSIV는 하이버네이트에서 사용하는 용어입니다.

JPA에서는 OEIV(Open EntityManager In View)라고 하지만, 관례상 다들 OSIV로 부릅니다.

 

 

영속성 컨텍스트가 살아있으면, 엔티티는 영속 상태로 관리되기 때문에 지연 로딩을 사용할 수 있습니다.

 

OSIV를 구현하는 방법을 알아보기 위해, 과거부터 현재까지의 OSIV 구현의 발전 과정을 살펴보겠습니다.

 

 

 

 

 

 

 

 

 

 

 

 

과거 OSIV - 요청 당 트랜잭션

OSIV의 가장 단순한 구현 방법은 클라이언트 요청이 들어오자마자 서블릿 필터 혹은 스프링 인터셉터에서 트랜잭션을 시작하고 요청이 끝날 때 트랜잭션도 끝내는 것입니다.

 

이것을 요청 당 트랜잭션 방식의 OSIV라 부릅니다. (Trascation per request)

 

 

 

 

 

 

 

문제점

위 방식의 문제점은 컨트롤러나 뷰 같은 프리젠테이션 계층이 엔티티를 변경할 수 있다는 점입니다.

 

 

 

예시를 하나 들어보겠습니다.

고객의 정보를 제공하는 기능을 만들었고, 화면상에는 보안을 위해 고객의 이름을 "XXX"처럼 변경해서 보여주어야 한다고 가정하겠습니다.

 

컨트롤러에서는 member를 가져와서 다음과 같은 코드를 작성할 것입니다.

Member member = memberService.getMember(id);
member.setName("XXX");
model.addAttribute("member", member);

 

위 코드의 결과로 어떠한 현상이 발생할까요?

 

당연히 화면상에는 XXX로 잘 보여질 것입니다.

그러나 OSIV 방식을 사용하였기에 member 엔티티는 영속 상태입니다.

 

따라서 변경감지 기능이 작동합니다.

 

 

즉 member의 이름이 아예 XXX로 바뀌어서 DB에 저장됩니다.

 

 

이런 문제를 해결하기 위해서는 프리젠테이션 계층에서는 엔티티를 수정하지 못하게 막으면 되는데, 다음과 같은 방법들이 있습니다.

• 엔티티를 읽기 전용 인터페이스로 제공
• 엔티티를 읽기 전용 메서드만 가진 Wrapper 클래스로 매핑
• DTO만 반환

 

위의 방법들은 모두 코드량이 상당히 증가한다는 단점들이 있습니다.

위의 문제들은 모두 요청 당 트랜잭션 방식을 사용하는 OSIV에서 발생하는 문제점들이고, 따라서 요즘에는 거의 사용하지 않습니다.

 

최근에는 이러한 문제점을 어느정도 보안해서 비즈니스 계층에서만 트랜잭션을 유지하는 방식의 OSIV를 사용하는데,

이것이 바로 스프링 프레임워크가 제공하는 OSIV입니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

스프링이 제공하는 OSIV - 비즈니스 계층 트랜잭션

스프링은 다양한 OSIV를 제공하는데, 이들 중 원하는 클래스를 선택해서 사용할 수 있습니다.

 

• 하이버네이트 OSIV 서블릿 필터 : org.springframework.orm.hibernate5.support.OpenSessionInViewFilter
• 하이버네이트 OSIV 스프링 인터셉터: org.springframework.orm.hibernate5.support.OpenSessionInViewInterceptor
• JPA OEIV 서블릿 필터 : org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter
• JPA OEIV 스프링 인터셉터 : org.springframework.orm.jpa.support.OpenEntityManagerInViewInterceptor

 

 

이전에 살펴보았던 요청 당 트랜잭션 방식의 OSIV는 프리젠테이션 계층에서 데이터를 변경할 수 있다는 문제점이 있었습니다.

그리고 스프링 프레임워크의 OSIV는 이런 문제점들을 어느정도 해결하였습니다.

 

 

스프링 프레임워크가 제공하는 OSIV는 비즈니스 계층에서 트랜잭션을 사용하는 OSIV 입니다

즉 OSIV를 사용하기는 하지만 트랜잭션은 비즈니스 계층에서만 사용한다는 뜻입니다.

 

 

스프링 OSIV - 비즈니스 계층 트랜잭션

 

 

동작 원리는 다음과 같습니다.

 

1. 클라이언트 요청이 들어오면 서블릿 필터 혹은 스프링 인터셉터에서 영속성 컨텍스트를 생성합니다. 단 이때 트랜잭션은 시작하지 않습니다.
2. 서비스 계층에서 @Transactional로 트랜잭션을 시작할 때 1번에서 미리 생성해둔 영속성 컨텍스트를 찾아와서 트랜잭션을 시작합니다.
3. 서비스 계층이 끝나면 트랜잭션을 커밋하고 영속성 컨텍스트를 플러시합니다. 이때 트랜잭션은 끝내지만 영속성 컨텍스트는 종료하지 않습니다.
4. 컨트롤러와 뷰까지 영속성 컨텍스트가 유지되므로 조회한 엔티티는 영속 상태를 유지합니다.
5. 서블릿 필터나 스프링 인터셉터로 요청이 돌아오면 영속성 컨텍스트를 종료합니다. 단 이때 플러시를 호출하지 않고 바로 종료합니다.

 

 

 

 따라서 영속성 컨텍스트는 프레젠테이션 계층까지 살려두면서, 변경은 불가능하게 만든 것입니다.

 

 

 

 

 

 

 

 

 

트랜잭션 없이 읽기

영속성 컨텍스트를 통한 모든 변경을 트랜잭션 안에서 이루어져야 합니다.

 

그러나 변경이 아닌 단순 조회의 경우에는 트랜잭션이 없어도 가능합니다.

 

이것을 트랜잭션 없이 읽기(Nontransaction reads)라 부릅니다.

 

프록시를 초기화하는 지연 로딩도 결국은 조회 기능이므로 트랜잭션 없이 읽기가 가능합니다.

 

 

 

 

 

 

 

 

 

 

 

스프링 OSIV 주의사항

스프링 OSIV를 사용하면 프리젠테이션 계층에서 엔티티를 수정해도 수정 내용을 데이터베이스에 반영하지 않는다고 하였습니다.

 

그러나 여기에 한 가지 예외 사항이 있습니다.

 

프리젠테이션 계층에서 엔티티를 수정한 직후에 트랜잭션을 시작하는 서비스 계층을 호출하면 문제가 발생합니다.

 

 

 

 

코드를 통해 알아보겠습니다.

@Controller
class MemberController {
    public String view(Long id){
    
    	Member member = memberService.getMember(id);
        member.setName("XXX");
        
        memberService.logic();// 트랜잭션을 시작하는 로직
        return "view"
    }
}

 

1. memberService의 getMember를 통해 찾아온 Member를 영속성 컨텍스트에 저장합니다. (트랜잭션은 시작하지 않았지만 영속성 컨텍스트는 존재하기 때문에 가능합니다.)
2. 찾아온 member의 이름을 XXX로 바꾸었습니다.
3. logic() 메소드를 호출하여 트랜잭션이 있는 비즈니스 로직을 실행하였습니다.
4. 트랜잭션 AOP가 동작하면서 영속성 컨텍스트에 트랜잭션을 시작합니다. 그리고 logic() 메소드를 실행합니다.
5. logic()메소드가 끝나면 트랜잭션 AOP는 트랜잭션을 커밋하고 영속성 컨텍스트를 플러시합니다. 이때 변경 감지가 동작하면서 회원 엔티티의 수정 사항을 데이터베이스에 반영합니다.

 

 

컨트롤러에서 엔티티를 수정하고 즉시 뷰를 호출한 것이 아니라, 트랜잭션이 동작하는 비즈니스 로직을 호출했으므로 이런 문제가 발생합니다.

 

문제를 해결하는 단순한 방법은 트랜잭션이 있는 비즈니스 로직을 모두 처리한 후 엔티티를 변경하는 것입니다.

 

 

 

 

 

 

트랜잭션이 같으면 항상 같은 영속성 컨텍스트를 사용하고, 영속성 컨텍스트와 트랜잭션의 생명주기가 동일하다고 하였습니다.

 

OSIV를 사용하지 않는 트랜잭션 범위의 영속성 컨텍스트 전략은 트랜잭션의 생명주기와 영속성 컨텍스트의 생명주기가 같으므로 지금까지 살펴보았던 문제가 발생하지 않습니다.

 

그러나 스프링 OSIV는 같은 영속성 컨텍스트를 여러 트랜잭션이 공유할 수 있으므로 이런 문제가 발생합니다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

OSIV 정리

 

스프링 OSIV의 특징

• 스프링 OSIV는 클라이언트의 요청이 들어올 때 영속성 컨텍스트를 생성해서 요청이 끝날 때까지 같은 영속성 컨텍스트를 유지합니다. 따라서 한 번 조회한 엔티티는 요청이 끝날 때까지 영속 상태를 유지합니다.
• 엔티티 수정은 트랜잭션이 있는 계층에서만 동작합니다. 트랜잭션이 없는 프리젠테이션 계층은 지연 로딩을 포함해서 조회만 할 수 있습니다.

 

 

 

 

 

스프링 OSIV의 단점

• OSIV를 사용하면 같은 영속성 컨텍스트를 여러 트랜잭션이 공유할 수 있다는 점을 주의해야 합니다. 특히 트랜잭션 롤백 시 주의해야 합니다.
• 프리젠테이션 계층에서 엔티티를 수정하고 난 후 비즈니스 로직을 수행하면 엔티티가 수정될 수 있습니다.
• 프리젠테이션 계층에서 지연 로딩에 의한 SQL이 실행됩니다. 따라서 성능 튜닝시에 확인해야 할 부분이 넓어집니다.
• 너무 오랜시간 동안 데이터베이스 커넥션 리소스를 사용합니다. 따라서 실시간 트래픽이 중요한 애플리케이션에서는 커넥션이 모자랄 수 있으며, 이것은 결국 장애로 이어질 수 있습니다.

 

 

 

 

 

 

 

 

 

 

 

 

OSIV   vs   FACADE   vs   DTO

OSIV의 저런 문제점들이 두렵다면 FACADE나 DTO를 만들어서 반환하는 방법을 사용할 수 있습니다.

어떤 방법이던 OSIV에 비해서는 코드를 많이 작성해야 합니다.

 

 

 

 

OSIV는 만능이 아닙니다.

OSIV는 복잡한 화면을 구성하는 경우 효과적이지 않을 수 있습니다.

예를 들어 복잡한 화면은 엔티티로 조회하기보다는 처음부터 DTO로 조회하는 것이 효과적입니다.

 

 

 

 

 

OSIV는 같은 JVM을 벗어난 원격 상황에서는 사용할 수 없습니다.

예를 들어 JSON이나 XML을 생성할 때는 지연 로딩을 사용할 수 있으나, 원격지인 클라이언트에서 연관된 엔티티를 지연 로딩하는 것은 불가능합니다.

결국 클라이언트가 필요한 데이터를 모두 JSON으로 생성해서 반환해야 합니다.

 

 

 

 

 

 

권장하는 방법

• 실시간 트레픽이 중요한 경우 OSIV를 사용하지 말고, DTO로 직접 조회하는 것을 권장합니다.
• 어드민 페이지같이 실시간 트레픽이 중요하지 않는 경우 OSIV를 사용해도 괜찮습니다.
• Command와 Query를 분리하는 것을 권장합니다.

 

 

 

 

 

 

Command와 Query 분리

깊게 들어가면 명령모델과 조회모델을 따로 두고 구현하거나 하는 방법까지도 갈 수 있지만, 여기서는 간단하게 명령과 조회를 분리하는 것에 대해서 언급하고자 합니다.

명령이라면 xxxService, 조회라면 xxxQueryService를 두고, QueryService에서 DTO를 Projection 하는 것이 핵심 비즈니스 로직에 영향을 주지 않으면서도, 문제 없이 효율적인 쿼리를 작성할 수 있는 구조를 가져갈 수 있게 도와줍니다

 

 

 

 

 

 

 

 

Reference

실전! 스프링 부트와 JPA 활용2 - API 개발과 성능 최적화 - 인프런 | 강의