문제점

• 각 계층에 대한 설명
• 어느정도 알아두는게 좋다

• 이런설명이있다 이제것 작성해왔던 코드는 뚱뚱한 서비스가 된다

• 서비스는 단순이 제어만하는 역할만 해야되는대 복잡한 비즈니스 로직을 어떻게 유지보수하냐고!
  

• 결과적으로 유지보수 하기 어려워..

• 트랜잭션 문제 / 예외 누수 문제 / JDBC 반복 문제

• 제어의 역전으로 해결등... 이런문제를 다 없애야된다.

트랜잭션 추상화

• JDBC에선 앞선 코드와 같이 Con.setAutocommit 을씀

• jpa 코드 이런것만 알아두자

• 이거 트랜 잭션 어노테이션 구현이랑 같다!

• 트랜잭션을 추상화하자

• txManager에 의존만하면됨
  
  

• 스프링은 이미 다 만들어놓음

• 내가 구현할 필요없음 이미다만들어짐

• 트랜잭션은 같은 데이터베이스 커넥션을 해야함 (동기화)

• 트랜잭션 동기화 매니저

• 트랜잭션 매니저는 트랜잭션 동기화 매니저 사용

• 쓰레드 로컬? 커넥션 안전하게 보관하는걸로만 알고 있자

• 트랜잭션 매니저는 트랜잭션 동기화 매니저에 커넥션을 보관함

• 쓰레드 로컬에다가 리소스들을 보관하는걸 확인할 수 있따

트랜잭션 문제해결 - 트랜잭션 매니저1

• DataSourceUtils 를 이용한 트랜잭션 동기화
• ReleaseConnection

• 트랜잭션 매니저를 주입 받는다. 지금은 JDBC 기술을 사용하기 때문에
• JPA 같은 기술로 변경되면 JpaTransactionManager 를 주입 받으면 된다.
• TransactionStatus status 를 반환한다. 현재 트랜잭션의 상태 정보가 포함되어 있다. 이후 트랜
  잭션을 커밋, 롤백할 때 필요하다
• ew DefaultTransactionDefinition()
  트랜잭션과 관련된 옵션을 지정할 수 있다. 자세한 내용은 뒤에서 설명

• 테스트 셋팅
• 트랜잭션매니저
• 트랜잭션 매니저는 데이터소스를 가지고 트랜잭션을 만든다 그래서 데이터소스를 트랜잭션 매니저에 넘겨줘야 함

• 마무리 설명

트랜잭션 문제 해결 - 트랜잭션 매니저2

• 설명이 잘ㅈ되있어서 일긱가 정말 편하다.

• 커넥션 꺼내옴 -> con.commit , con.rollback() 가져와서 하는구나.

• 트랜잭션 추상화 덕분에 서비스 코드는 이제 JDBC 기술에 의존하지 않는다.

• 이후 JDBC에서 JPA로 변경해도 서비스 코드를 그대로 유지할 수 있다.

• 기술 변경시 의존관계 주입만 DataSourceTransactionManager 에서 JpaTransactionManager 로 변경해주면 된다.

• java.sql.SQLException 이 아직 남아있지만 이 부분은 뒤에 예외 문제에서 해결하자.

트랜잭션 문제 해결 - 트랜잭션 템플릿

• 반복코드가 너무 발생
• 이걸 해결해보자
• 템플릿 콜백 패턴 이해하지못해도 Ok TransactionTemplate 편리기능을 제공하는구나 정도 이해

• 예제 기억해두자

• 트랜잭션 템플릿을 쓰려면 트랜잭션 매니저가 필요함.

• Execute WithoutResult 실행하면 코드 안에서 커밋 OR 롤백 예외가 처리됨

• 테스트는 기존하고 같아서 패스

• 트랜잭션 로직이 서비스에? 두 가지 관심사가 하나의 클래스에서처리
• 코드의 유지보수 어려워짐 해결해야됨

트랜잭션 문제 해결 - 트랜잭션 AOP 이해

• 이런식으로 변경해 간다

• 프록시를 사용하면 트랜잭션을 처리하는 객체와 비즈니스 로직을 처리하는 서비스 객체를 명확하게 분리할 수 있다.

• 스프링이 자동으로 만들어주는 코드 트랜잭셔널 어노테이션 구현 코드이다

• 트랜잭셔널 어노테이션 적용후

트랜잭션 AOP 적용

• 순수 비즈니스 로직만 남게됨
• Transactional 애노테이션은 메서드에 붙여도 되고, 클래스에 붙여도 된다. 클래스에 붙이면 외부에서
  호출 가능한 public 메서드가 AOP 적용 대상이 된다

• 테스트코드를 수정했는대 적용이 안됀다
• 스프링을 사용하지 않고 직접 적용 했기 때문

• 이런식으로 변경해줘야 됨

• @SpringBootTest : 스프링 AOP를 적용하려면 스프링 컨테이너가 필요하다. 이 애노테이션이 있으면 테 스트시 스프링 부트를 통해 스프링 컨테이너를 생성한다. 그리고 테스트에서 @Autowired 등을 통해 스프 링 컨테이너가 관리하는 빈들을 사용할 수 있다.

• @TestConfiguration : 테스트 안에서 내부 설정 클래스를 만들어서 사용하면서 이 에노테이션을 붙이면, 스프링 부트가 자동으로 만들어주는 빈들에 추가로 필요한 스프링 빈들을 등록하고 테스트를 수행할 수 있 다.

• TestConfig
  DataSource 스프링에서 기본으로 사용할 데이터소스를 스프링 빈으로 등록한다. 추가로 트랜잭션
  매니저에서도 사용한다.
  DataSourceTransactionManager 트랜잭션 매니저를 스프링 빈으로 등록한다.
  스프링이 제공하는 트랜잭션 AOP는 스프링 빈에 등록된 트랜잭션 매니저를 찾아서 사용하기 때 문에 트랜잭션 매니저를 스프링 빈으로 등록해두어야 한다.

• 이걸 보고 스프링부트 테스트네? 스프링을 임시로 하나 띄워주고 필요한 빈을 등록해줌

• 부가 정보

AOP 정리

선언전 트랙잭션 관리 Vs 프로그래밍 방식 트랜잭션관리

• @Transactional 애노테이션 하나만 선언해서 매우 편리하게 트랜잭션을 적용하는 것을 선언적 트
  랜잭션 관리라 한다.

• 선언적 트랜잭션 관리는 과거 XML에 설정하기도 했다. 이름 그대로 해당 로직에 트랜잭션을 적용하겠 다 라고 어딘가에 선언하기만 하면 트랜잭션이 적용되는 방식이다

• 트랜잭션 매니저 또는 트랜잭션 템플릿 등을 사용해서 트랜잭션 관련 코드를 직접 작성하는 것을 프로 그래밍 방식의 트랜잭션 관리라 한다.

• 선언적 트랜잭션 방식이 간결하고 편하기 때문에 더많이 선호하고 사용함

스프링 부트 자동 리소스

• 스프링 부트가 등장하기 이전에는 데이터소스와 트랜잭션 매니저를 개발자가 직접 스프링 빈으로 등록해서 사용했다. 그런데 스프링 부트로 개발을 시작한 개발자라면 데이터소스나 트랜잭션 매니저를 직접 등록한 적이 없을 것이다.

• 헉 그러네 yml 등록되있지

데이터소스 - 자동 등록

• 스프링 부트는 데이터소스( DataSource )를 스프링 빈에 자동으로 등록한다.
  자동으로 등록되는 스프링 빈 이름: dataSource
  참고로 개발자가 직접 데이터소스를 빈으로 등록하면 스프링 부트는 데이터소스를 자동으로 등록하지 않는 다.

• yml 설정을 무시한다는 의미인가.

• 이때 스프링 부트는 다음과 같이 application.properties 에 있는 속성을 사용해서 DataSource 를 생 성한다. 그리고 스프링 빈에 등록한다.

• 스프링 부트가 기본으로 생성하는 데이터소스는 커넥션풀을 제공하는 HikariDataSource 이다. 커넥션풀 과 관련된 설정도 application.properties 를 통해서 지정할 수 있다.
  spring.datasource.url 속성이 없으면 내장 데이터베이스(메모리 DB)를 생성하려고 시도한다.

트랜잭션 매니저 - 자동 등록

• 스프링 부트는 적절한 트랜잭션 매니저( PlatformTransactionManager )를 자동으로 스프링 빈에 등록한 다.
  자동으로 등록되는 스프링 빈 이름: transactionManager
  참고로 개발자가 직접 트랜잭션 매니저를 빈으로 등록하면 스프링 부트는 트랜잭션 매니저를 자동으로 등록 하지 않는다.

• 다 자동으로 등록이 되네..

• 어떤 트랜잭션 매니저를 선택할지는 현재 등록된 라이브러리를 보고 판단하는데, JDBC를 기술을 사용하면 DataSourceTransactionManager 를 빈으로 등록하고, JPA를 사용하면 JpaTransactionManager 를 빈으로 등록한다. 둘다 사용하는 경우 JpaTransactionManager 를 등록한다. 참고로 JpaTransactionManager 는 DataSourceTransactionManager 가 제공하는 기능도 대부분 지원