Simple Record

Spring의 핵심 요소는

- 제어 역전(IoC, Inversion of Control)

- 관점 지향 프로그래밍(AOP, Aspect Oriented Programming)

- 서비스 추상화(PSA, Portable Service Abstraction)

라고 볼 수 있다.

오늘 볼 것은 IoC, 제어의 역전을 위한 DI(Dependency Injection)에 대해서 알아보고자 한다.

참고로 DI는 스프링에만 있는 것이 아니다. DI는 디자인 패턴 중 하나이다.

DI, 의존성 주입은 무엇일까, DI에 대해 이야기하기 전에 먼저 의존성이라는 것에 대해 알아야한다.

의존성이랑 A객체 내 B객체가 사용될 때 A는 B에 대해 의존성을 가진다고 한다. 이유인 즉슨 B가 바뀌게 되거나 다른 객체를 사용해야할 때 그 영향을 A도 받기 때문이다. 이런 의존성은 개발 또는 유지보수를 힘들게 한다.

따라서 우리는 결합도는 낮고 응집도는 높게 개발할 필요가  있다.

그러면 어떻게 의존성을 줄일 수 있을까, 그것은 객체를 직접 만들지 않고 외부에서 만들어서 객체를 넣어주는 방식을 사용하면 된다. 이런 것을 우리는 DI라고 부른다.

그러면 DI의 방법은 무엇이 있을까

- 생성자 주입

- Setter 주입

생성자 주입의 예

B b = new B();
A a = new A(b);

a를 생성하기 전 객체 b를 생성하여 a를 생성할 때 b를 생성자를 통해 주입해준다.

Setter 주입의 예

B b = new B();
A a = new A();
a.setB(b);

이번에는 객체 b를 생성하고 객체 a를 생성한 후 a의 setB메서드를 통해 객체 b를 주입해준다.

이렇게 되면 우리가 주입한 객체에 따라 a가 동작하게 되고 a는 b가 다른 객체가 주입되면 다른 객체에 맞게 동작할 수 있다.

그런데 어떻게 다른 객체를 주입할 수 있을까

그것은 인터페이스를 이용하면 된다.

우리가 a 내에 b를 주입 받을 필드를 B클래스의 레퍼런스 변수를 지정하면 우리는 B밖에 주입할 수 없다.

그러나 B 대신 B가 구현하고 있는 인터페이스 SuperB를 사용해서 레퍼런스 변수를 만든다면 우리는 SuperB를 구현하고 있는 객체를 주입할 수 있게 된다.

SuperB를 구현한 Class인 B와 BB 그리고 BBB가 있을 때 우리는 a에 B, BB, BBB를 주입할 수 있다.

이렇게 되면 우리의 프로그램이 필요한 객체를 SuperB인터페이스에 맞게 구현해서 주입한다면, A 클래스를 수정하지 않아도 주입된 객체에 따라 A의 객체를 동작을 변경할 수 있게 된다.

JAVA를 처음 배울 때 인터페이스가 왜 필요하지라는 생각을 많이 갖고 있었는데, 스프링이나 디자인 패턴들을 공부할 때마다 인터페이스의 활용도가 높다는 것을 느낀다.

Spring의 핵심 요소는

- 제어 역전(IoC, Inversion of Control)

- 관점 지향 프로그래밍(AOP, Aspect Oriented Programming)

- 서비스 추상화(PSA, Portable Service Abstraction)

라고 볼 수 있다.

IoC는 우리가 제어의 역전이라고 알고 있다.

그렇다면 제어의 역전이라는 것은 무엇일까, 일반적으로 프로그램을 개발할 때 개발자(주체)가 객체의 생명 주기를 관리하게 된다. 제어의 역전이란 외부(컨테이너, 주체)에서 객체의 생명 주기를 관리하는 것이다.

이러한 IoC를 위해 DI(Dependency Injection)이 사용된다.

Spring IoC컨테이너가 우리가 필요한 인터페이스 자리에 객체를 생성해서 넣어준다(DI).

Spring에서는 IoC 컨테이너로 ApplicationContext 인터페이스를 구현한 오브젝트(객체)이다.

추가로 ApplicationContext는 BeanFactory를 상속한 하위 인터페이스이다.

IoC컨테이너를 통해 Bean이 관리된다.

Bean이란 IoC컨테이너가 관리하는 대상(객체)이다.

IoC컨테이너가 객체를 관리하기 위해서는 Bean을 IoC컨테이너에 등록해 주어야 한다.

등록하는 방법은 xml을 통한 방법과 java를 이용하는 방법이 있다.

방법은 추가로 등록하겠습니다.

Spring에서 DB에 대한 연산을 할 때 

@Transactional 어노테이션을 통해 트랜젝션 작업 단위로 묶어서 처리한다.

트랜젝션을 위해 @Transactional 어노테이션을 붙여도 동작하지 않는 상황에 주의해야한다.

1. @Transactional을 붙인 메서드의 접근지정자가 private인 경우

public class GameService {
	
	//..........
    
	public void doSave() {
		save();
	}
    
	@Transactional
	private void save() {
		//..........
	}
	
}

이는 Spring AOP가 프록시 기반으로 하기 때문에 발생하는 것으로 접근지정자를 public으로 지정하면 된다.

2.  @Transactional이 붙지 않은 메서드에서 @Transactional이 붙은 메서드를 호출하는 경우

public class GameService {
	
	//..........
    
	public void doSave() {
		save();
	}
    
	@Transactional
	public void save() {
		//..........
	}
	
}

@Transactional은 Proxy를 이용해 메서드가 실행되기 전 트랜젝션을 묶게 된다. 따라서 @Transactional이 붙지 않은 doSave() 메서드를 호출하게되면 트랜젝션이 적용되지 않은 상태로 doSave() 메서드를 실행하고 이 메서드 내에서 save() 메서드를 호출하게 되므로 save() 메서드에 트랜젝션이 정상적으로 적용되지 않는다.

해결방법

- doSave를 통해 save를 호출하는게 아닌 save 메서드를 호출하게 되면 정상적으로 트랜젝션이 동작하게 된다.

- doSave메서드에 @Transactional 어노테이션을 붙인다.

public class GameService {
	
	//..........
    
	@Transactional
	public void doSave() {
		save();
	}
    
	@Transactional
	public void save() {
		//..........
	}
	
}

Spring의 핵심 요소는

- 제어 역전(IoC, Inversion of Control)

- 관점 지향 프로그래밍(AOP, Aspect Oriented Programming)

- 서비스 추상화(PSA, Portable Service Abstraction)

라고 볼 수 있다.

오늘은 그 중에서 AOP에 대해서 정리해보려고 한다.

AOP란 무엇일까?AOP는Aspect Oriented Programming, 관점 지향 프로그래밍은 절차지향 프로그래밍과 같이하나의 패러다임이라고 볼 수 있다.

AOP는 좀 더 비즈니스 로직에 집중하는 것을 말한다.

가령 우리가 어떤 물품을 판매하는 사이트를 만들었다고 가정하면,

그 안에는 여러 기능들이 존재할 것이고 그 기능들은 데이터베이스를 통해 데이터를 가져오거나 저장할 것이다.

이러한 경우, 데이터베이스에 데이터를 쓰거나 읽을 때 우리는 트랜젝션을 통해 논리적 작업단위로 묶어서 데이터를 처리한다.

그렇다면 각 기능에는 트랜젝션과 비즈니스 로직이 함께 들어가야할 것이다.

비즈니스 로직을 개발할 때 공통의 중복된 기능을 주입하여 비즈니스 로직에만 더 집중해서 개발하고자 하는게 관점 지향적 프로그래밍의 핵심이라고 볼 수 있다.

즉, 내가 필요한 기능이 있다면 기능을 주입해서 사용할 수 있는 것이다.

가장 좋은 예시가 Spring의 @Transactional이다.

우리가 Spring을 통해 개발할 때 메서드나 Class 위에 @Transactional 어노테이션을 사용한다.

이런 경우 우리가 작성한 데이터 처리 메서드가 시작될 때 그리고 종료될 때에 맞춰서 트랜젝션이 시작되고 종료된다.

우리에게 필요한 공통 기능을 만들고 필요할 때 주입해서 사용함으로서 좀 더 비즈니스 로직에 집중할 수 있도록 하는게 AOP이다.

추가로 Spring의 AOP는 프록시(다이나믹 프록시)를 통해 AOP를 구현하고 있다.

우리가 어떤 메서드를 호출하게 되면 이를 프록시가 대신 실행해주면서 추가적인 기능을 실행해주게 된다.

A 메서드 실행하고자 할 때 이를 프록시에게 맡겨서

프록시 -> 추가기능 실행 -> A 메서드 실행 이런식으로 동작하게 된다.

다음에는 Spring의 AOP동작에 대해서 작성해보겠다.

틀린점이나 추가해야할 것이 있다면 알려주세요.

Filter는 말 그대로 요청이나 결과를 Filtering 하는 역할을 수행한다.

Servlet과 Spring의 구조를 정말 잘 표현한 이미지이다.

Filter는 Servlet Stack으로 Dispatcher Servlet 앞단에 위치하고 있으며, Filter Chain으로 동작한다.

Filter는 Filter interface를 구현하면 되고 doFilter 메소드를 호출하면 chain 형식으로 다음 필터를 호출하는 식으로 동작 한다.

Interceptor랑 햇갈리는 경우가 많은데,

Interceptor의 위치는 Dispatcher Servelt에 요청이 들어온 다음에 위치하고 있다.

Filter와 Interceptor는 지향하는 점이 다르다고 할 수 있다.

물론 둘 다 요청과 응답을 제어할 수 있다는 점에 대해서는 같지만,

대체적으로 Filter의 경우 요청과 응답에 대한 처리가 필요한 경우(인증 등) 사용하는 경우가 많고,

Interceptor는 Business 로직에 좀 더 지향적인 처리가 필요한 경우(트랜잭션 등) 사용하는 경우가 많다.

스프링의 전체적인 실행 흐름을 알기 위해서는 Servlet에 대해서 먼저 이해하는게 좋다.

그렇다면 서블릿이란 무엇인가?

이를 알기 위해 과거로 돌아가 보면 과거의 웹 페이지들은 주로 정적인 HTML 페이지로 구성되어있고, 이러한 것은 동적인 컨텐츠를 보여주는데 한계가 있었다.

ex) 로그인하면 OOO님 안녕하세요! 같은 것을 보여주는 것

이러한 동적인 컨텐츠를 만들어 내기위해 자바 진영에 만들어진 웹 기술이 바로 Servlet이다.

Servlet은 HttpServlet 클래스는 클래스를 구현하여 만들 수 있다.

class TestServlet extends HttpServlet {
		// 이런 느낌
}

그리고 사용자의 요청에 맞는 Servlet을 찾아 실행하고 관리하는 역할을 하는 것이 Servlet Container 이고 우리가 알고있는 Tomcat 이고 WAS(Web Application Server)라고 부른다.

그리고 이러한 동적인 웹 컨텐츠를 생성하는 것이 아닌 정적인 컨텐츠 HTML, CSS 등을 제공하는 것이 바로Apache HTTP Server WEB 서버다.

보통 우리가 아파치 톰캣이라고 부르는 것은 이 둘을 말하는 것이다.

Servlet의 아래의 과정으로 실행이 된다.

1. init() : 인스턴스가 생성될 후 최초 한번 수행 하는 메소드
2. service() → doGet() / doPost() 등 : 요청을 받으면 service 메소드가 실행되고 요청 메소드에 따라 doGet, doPost 중 선택되어 실행 하여 비즈니스 로직 수행 후 결과 반환
3. destroy() : 서즐릿 종료시 호출되는 메소드

이처럼 서블릿을 이용하면 정해져있는 메소드를 구현 하기만 하면 비즈니스 로직을 수행할 수 있다.

좋은 것 처럼 보인다.

그런데 과연 홈페이지의 기능이 하나가 아니라면? ⇒ 필요한 기능을 구현한 파일이 많아진다.

그리고 구현된 것을 다른 곳에 사용하고 싶다면 과연 어떻게 될까? ⇒ HttpServlet을 extends하고 있어서 다른 곳에서 사용하기는 어려워 보인다.

우리의 java 파일은 점점 많아지게 되고 이를 유지보수 하기 어려워진다.

이러한 문제를 해결하기 위한 시도에 의해 생겨난 것이 Spring 이다.