스프링 총정리

 

 

---

주요 키워드

 

IoC (제어의 역전)

 

IoC (Inversion of Confrol, 제어의 역전) : 다른 객체를 직접 생성하는 대신, 외부에서 관리하는 객체를 가져와 사용하는 것

 

전통적인 프로그래밍에서는 개발자가 프로그램의 흐름과 제어를 직접 다뤄야 했다.

하지만 그렇다 보니, 아무리 다형성에 맞게 설계를 구현하더라도 구현 방식의 변경이 발생하면 클라이언트 코드에서 구현 방식을 선택하는 부분이 수정될 수 밖에 없었다.

이는 OCP 원칙과 DIP 원칙의 위반으로 이어진다!

• OCP 원칙 위반 : 수정 사항 발생에 따라 클라이언트 코드를 수정해야 함
• DIP 원칙 위반 : 클라이언트 코드의 구현 방식을 선택하는 부분은 인터페이스가 아닌 구현체에 의존적임

 

하지만, 스프링 프레임워크는 이러한 문제를 해결해준다.

스프링 프레임워크가 객체의 생성 및 관리와 프로그램의 제어 흐름을 담당해주기 때문이다.

스프링은 이를 위해 스프링 컨테이너(ApplicationContext)를 제공한다.

 

스프링 컨테이너는 빈을 생성하고 관리한다.

이 스프링 빈은 스프링이 제어하며, 해당 객체의 생성 및 관리에 개발자는 관여하지 않는다.

해당 빈이 필요하다면 의존성 주입(DI)를 통해 스프링 컨테이너가 객체를 주입해준다.

 

이러한 제어의 역전 기술을 통해 얻을 수 있는 이점은 다음과 같다.

• 개발자가 직접 의존 객체를 생성하고 관리하지 않아도 된다.
• 클래스 간의 의존도가 줄어듦으로써, 하나의 클래스가 변경되어도 다른 클래스에 미치는 영향이 적어지므로, 코드 변경이 쉬워지고 재사용성이 좋아진다.
• 객체가 자신의 로직에만 집중할 수 있으므로, 코드가 깔끔해지고 역할이 명확해진다.

 

---

 

DI (의존 관계 주입)

 

DI (Dependency Injection, 의존 관계 주입) : 객체 간의 의존성을 프레임워크가 주입하는 것

 

의존하는 객체를 객체가 직접 생성하거나 참조하는 대신, 의존성을 외부로부터 주입받을 수 있다.

IoC를 구현 가능하게 해주는 대표적인 수단이다.

 

DI에는 생성자 주입, 필드 주입, Setter 주입 등의 여러 방식이 존재한다.

그 중 생성자 주입 방식이 가장 권장되는 추세이다!

 

생성자 주입 방식의 장점은 다음과 같다.

• 객체의 불변성 확보
• 테스트 코드 작성의 용이성
• final 키워드를 통해 누락된 의존성 확인
• Lombok과 결합하여 간결한 코드 작성 가능
• 스프링에 의존적이지 않음
• 순환 참조 에러를 컴파일 타임에 감지 가능

 

---

 

AOP (관점 지향 프로그래밍)

 

AOP (Aspect-Oriented Programming, 관점 지향 프로그래밍) : 기능을 구현할 때 핵심 기능과 부가 기능을 구분하여 각각을 하나의 관점으로 묶어서 개발하는 방식

 

핵심 로직 사이사이에 존재하는 로깅, 트랜잭션 관리 등의 부가적인 코드와 핵심 로직을 분리할 수 있다.

또한, 여러 기능에 반복적으로 등장하는 부가 기능을 하나의 공통 로직으로 처리하도록 모듈화 할 수 있다.

 

AOP를 통해 부가 기능의 코드 중복을 줄이고, 유지보수성을 높일수 있다.

 

 

AOP는 프록시 디자인 패턴을 사용한다.

여기서 프록시 패턴이란 클라이언트가 대상 객체와 동일한 인터페이스를 가진 프록시 객체에 접근하도록 함으로써, 대상 객체에 대한 접근을 제어하는 디자인 패턴이다.

 

스프링은 대상 객체에 대한 프록시 객체를 생성한다.

클라이언트가 해당 객체의 메서드를 호출하면, 프록시가 중간에 가로채서 AOP 등의 부가 기능을 끼워넣는 것이다.

 

---

스프링 MVC 동작 과정

 

 

위 그림은 스프링 MVC가 동작하는 과정을 보여준다.

차근차근 하나씩 살펴보도록 하자!

1. DispatcherServlet이 모든 클라이언트의 요청을 받는다.
2. DispatcherServlet이 HandlerMapping으로부터 들어온 요청을 처리할 수 있는 handler(컨트롤러 등) 객체를 가져온다.
3. DispatcherServlet이 handler 객체의 메서드를 호출할 수 있는 HandlerAdapter 객체를 가져온다.
4. handler 객체의 메서드를 호출한다.(컨트롤러가 서비스를 통해 비즈니스 로직을 처리)
5. 결과를 모델 객체에 저장한 후, DispatcherServlet에게 view name을 반환한다.
6. DispatcherServlet이 view name을 View Resolver에 전달하여 뷰 객체를 얻는다.
7. DispatcherServlet이 뷰 객체에게 출력될 화면을 요청한다.
8. 뷰가 모델로부터 필요한 데이터를 가져와서 화면을 출력한다.

 

 

---

 

 

참고:

https://innovation123.tistory.com/167#DI(Dependency%20Injection)%20%3A%20%EC%9D%98%EC%A1%B4%EC%84%B1%20%EC%A3%BC%EC%9E%85-1

https://yenbook.tistory.com/6