Spring mvc,트랜잭션

ttomy·2022년 1월 18일

Spring

개념정리

목록 보기

6/6

mvc

model,view,controller의 약자
model: 뷰가 랜더링하는데 필요한 데이터. 사용자가 요청한 상품목록이나,주문내역, 상품의 정보등이 해당한다.

view: 실제로 보여지는 부분.jsp,pdf,xml등으로 표현
controller: 사용자의 액션에 응답하는 컴포넌트. 모델을 업데이트 하고 동작을 수행

jsp에 자바코드와 html코드가 섞여있어 유지보수가 어려움.

jsp가 뷰의 역할에만 충실하고 servelet에서 요청과 데이터를 처리하는 역할을 맡아서 로직과 뷰를 분리할 수 있게 된다.

spring mvc의 구성요소와 동작

레이어드 아키텍쳐

싱글톤 패턴

싱클톤 패턴이란 객체의 인스턴스가 오직 1개만 생성되는 패턴을 의미한다. 생성자가 여러차례 호출되더라도 실제로 생성되는 객체는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 객체를 만들어 리턴한다.
아래는 싱클톤 패턴의 단순한 구현 예이다.

public class Singleton {

    private static Singleton instance = new Singleton();
    
    private Singleton() {
        // 생성자는 외부에서 호출못하게 private 으로 지정해야 한다.
    }

    public static Singleton getInstance() {
        return instance;
    }

    public void say() {
        System.out.println("hi, there");
    }
}

참고: https://tecoble.techcourse.co.kr/post/2020-11-07-singleton/

싱글톤 패턴의 이점은 메모리 낭비를 줄일 수 있다는 점이다. 최초의 생성을 통해 고정된 메모리 영역을 사용하기 때문에 객체에 접근할 떄 메모리 낭비를 줄일 수 있고 이미 생성된 인스턴스를 활용하기 때문에 속도 면에서도 유리하다.

참고: https://jenny-daru.tistory.com/31
또한 다른 클래스 간의 데이터 공유가 쉽다.

IOC

ioc란 inversion of control, 즉 제어의 역전이다. 제어권이 역전 되었다는 말인데 이게 무슨 뜻일까.
자바 기반의 어플리케이션이 개발되던 초기에는 객체를 생성하고 의존관계를 설정하는 등의 제어권을 개발자가 직접 가지고 있었다. 하지만 servelet이 등장하고, sevelet을 관리하는 컨테이너가 객체의 생성,생명주기의 관리와 같은 작업을 수행하게 되며 제어권이 넘어간 것을 ioc라 한다.

DI

참고: https://www.nextree.co.kr/p11247/

-DI/IOC가 적용되지 않은 경우

public class Foo{
	private Bar bar;
    
    public Foo(){
    	bar = new SubBar();
    }
}

-DI/IOC가 적용된 경우

public class Foo{
	private Bar bar;
    
    public Foo(Bar bar){
    	this.bar=bar;
    }
}

DI가 적용되지 않았을 경우는 Bar 구현체의 생성자가 그대로 Foo안에서 노출된다. 이 경우 동적으로 구현 클래스를 정하기 어렵다. 예를 들어 Subbar를 MainBar로 교체할 일이 발생하면 Foo가 정의된 부분까지 가서 new MainBar()로 바꿔줘야 한다는 것이다 이는 객체지향의 장점을 살리지 못하는 방법이다.
DI가 적용된 경우, 즉 만들어진 객체를 주입하는 방식은
Foo()에 인자를 다르게 넣어주는 것만으로 동적으로 구현체를 할당해 줄 수 있다.

AOP

aspect oriented programming, 즉 관점지향 프로그래밍이다.
이는 쉽게말하면 관심사를 핵심 로직과 구분해 관점에 따라 나누고 이 나눈 것들을 모듈화 시키겠다는 것이다.
객체지향 프로그래밍은 클래스들을 책임과 관심사에 따라 분리한다. 그러나 이로인해 한 기능(관심사)이 여러 클래스에 걸쳐 존재하는 방식으로 구현이 된다.

AOP가 필요한 상황?
클래스의 공통관심사란 무엇인가.
예를 들어 모든 메소드의 실행 시간을 측정해야 한다면 모든 메소드 안에 들어가 시간을 측정하는 코드 입력하는 번거로운 상황이 생길 수 있다.
하지만 이 시간 측정은 핵심 로직이 아니다. 핵심 로직은 각 메소드들이 처음에 수행하기 위해 구현한 기능(핵심 관심사)들이고, 이를 시간 측정 코드(공통 관심사)와 구분해야 한다.
스프링은 이런 AOP를 @Aspect, @Around 등의 어노테이션으로 지원한다.
AOP동작 과정
가짜를 만들어내고 (프록시) 이 프록시가 끝나면 joinPoint.proceed가 호출되면 진짜가 실행된다.

트랜잭션

하나의 논리적인 작업

트랜잭션의 특징

원자성: 전체가 실패하거나 성공해야 한다.
-> 트랜잭션 안의 특정 과정에서 실패했다면 rollback되어 이 결과가 반영되어서는 안된다. 모든 과정이 성공했을 경우에만 commit되어야 한다.
ex) 내 계좌에서 500만원을 홍길동에게 송금하는 트랜잭션 중 계좌에서 500만원을 인출하는 것까지만 성공하고 홍길동에게 송금하는 과정 중 실패한다면 500만원의 인출이 반영되서는 안된다.
일관성: 트랜잭션이 진행되는 동안 데이터가 변경되더라도 처음에 참조한 데이터로 진행된 결과가 도출되어야 한다.
독립성: 둘 이상의 트랜잭션이 병행 실행될 경우, 다른 트랜잭션이 완료되기 전인 트랜잭션의 결과를 참조할 수 없다.
지속성: 트랜잭션이 성공적으로 완료되면 수정되기 전까지 영구적으로 반영되어야 한다.

spring에서는 @Transactional 등의 어노테이션으로 트랜잭션 구현을 지원해주고 jpa에서는 한 트랜잭션 안에서의 동일한 호출은 동일한 결과를 반환하도록(다른 트랜잭션이라면 다른 인스턴스로부터 다른 반환값 받을 우려 있음) 지원한다.

ttomy

이전 포스트