[기술면접] SpringFramework

Spring Framework란 

스프링 프레임워크는 자바를 위한 오픈소스 애플리케이션 프레임워크로서 자바 기반 엔터 프라이즈 개발을 위해 다양한 서비스를 제공

 

Spring MVC

Spring MVC는 웹 애플리케이션 개발을 위한 MVC패턴 기반의 웹 프레임워크이다. Spring MVC는 애플리케이션 구성요소를 Model, View, Controller로 분리한다. 또한 Spring MVC는 아래와 같은 컴포넌트들로 구성된다.

• Dispatcher Servlet :  클라이언트의 요청을 먼저 받아들이는 서블릿으로 요청에 맞는 컨트롤러에게 요청을 전달함
• Handler Mapping : 해당 요청이 어떤 컨트롤러에게 온 요청인지 검사함
• Controller : 클라이언트의 요청을 받아 처리하여 결과를 디스패처 서블릿에게 전달함
• View Resolver : View의 이름을 통해 알맞은 View를 찾음
• View : 사용자에게 보여질 UI화면 

Spring MVC 작동원리

https://mangkyu.tistory.com/18

1. 클라이언트는 URL을 통해 요청을 전송한다.
2. 디스패처 서블릿은 핸들러 매핑을 통해 해당 요청이 어느 컨트롤러에게 온 요청인지 찾는다.
3. 디스패처 서블릿은 핸들러 어댑터에게 요청을 전달한다.
4. 핸들러 어댑터는 해당 컨트롤러에 요청을 전달한다.
5. 컨트롤러는 비즈니스 로직을 처리한 후에 반환할 뷰의 이름을 반환한다.
6. 디스패처 서블릿은 뷰 리졸버를 통해 반환할 뷰를 찾는다.
7. 디스패처 서블릿은 컨트롤러에서 뷰에 전달할 데이터를 추가한다.
8. 데이터가 추가된 뷰를 반환한다.

Spring MVC 장단점

• 장점
  • 의존성 주입을 통해 컴포넌트 간의 결합도를 낮출 수 있어 단위 테스트가 용이하다.
  • 제어의 역전을 통해 객체의 라이프 사이클에 관여하지 않고 개발에 집중할 수 있다.
• 단점
  • XML을 기반으로 하는 프로젝트 설정은 너무나 많은 시간을 필요로 한다.
  • 톰캣과 같은 WAS를 별도로 설치해주어야 한다.

Servlet

서블릿이란 클라이언트의 요청을 처리하고, 그 결과를 반환하는 Servlet 클래스의 구현 규칙을 지킨 자바 웹 프로그래밍 기술이다.

Spring MVC에서 Controller로 이용되며, 사용자의 요청을 받아 처리한 후 결과를 반환한다.

 

Dispatcher Servlet

디스패처 서블릿은 톰캣과 같은 서블릿 컨테이너를 통해 들어오는 모든 요청을 제일 앞에서 받는 컨트롤러이다.

디스패처 서블릿은 공통된 작업을 처리한 후에 적절한 세부 컨트롤러로 작업을 위임해준다. 그리고 각각의 세부 콘트롤러는 처리할 부분을 처리하고 반환할 view를 Dispatcher servlet에 넘기게 된다.

 

Springboot

• 자동 설정을 도입해서 디스패처 서블릿 등과 같은 설정시간을 줄여준다.
• 프로젝트의 의존성을 독립적으로 선택하지 않고 spring-boot-starter로 모아두어 외부 도구들을 사용하기 편리하다.
• 내장 톰캣을  제공하여  별도의 WAS를 필요로 하지 않음

Springboot와 Springframework

스프링 부트와 스프링 프레임워크의 가장 큰 차이는 Auto Configuration이다.

Spring MVC 프로젝트를 스프링 프레임워크 기반으로 구성하면 컴포넌트 스캔, Bean설정 , Dispatcher Servlet 설정, View Resolver, JDBC 설정 등 많은 설정을 해야 하지만 이를 SpringBoot기반으로 구성함으로써 초기 개발 환경 세팅에 걸리는 리소스를 절약할 수 있다.

스프링 부트로 프로젝트를 생성할 시 스프링 부트에서는 내장 서브릿 컨테이너인 톰캣이 자동적으로 설정된다.

 

@Bean,@Configuration,@Component

개발자가 직접 제어가 불가능한 외부 라이브러리 또는 설정을 위한 클래스를 Bean으로 등록할 때,@Bean 어노테이션을 활용한다.

1개 이상의 @Bean을 제공하는 클래스의 경우 반드시 @Configuration을 명시해주어야 한다.

개발자가 직접 개발한 클래스를 Bean으로 등록하고자 하는 경우 @Component 어노테이션을 활용한다.

 

스프링 Bean 주입 방법

@Autowired 어노테이션으로 필드에 주입받을 수도 있고, 생성자를 통해서 주입을 받을 수도 있고, Setter를 통해 주입받을 수 있다.

Bean 주입 시 같은 이름 및 같은 타입의 Bean이 존재한다면 @Primary어노테이션으로 우선순위를 설정할 수 있다.

 

스프링 컨테이너

프레임워크 안에서 인스턴스들의 생명 주기를 관리하며 , 생성된 인스턴스에 추가적인 기능을 제공한다.

내가 작업한 코드 처리 과정이 컨테이너에서 실행된다.

스프링 컨테이너는 스프링 프레임워크의 핵심적인 위치에 존재하며 DI를 통한 애플리케이션을 구성하는 컴포넌트를 관리한다.

 

스프링 컨테이너 종류

BeanFactory : DI의 기본 사항을 제공하는 컨테이너, 빈을 생성하고 분배하는 작업을 한다.

Application Context : bean factory와 유사하지만 더 많은 기능을 제공한다.  미리 빈을 생성해놓아 빈이 필요할 때 즉시 사용할 수 있도록 보장한다.

 

VO, DTO, DAO, BO

VO(Value Object) : 실제 데이터만을 저장하는 클래스

DTO(Data Transfer Object) : 데이터를 주고받기 위해 사용하는 클래스

DAO(Data Access Object) : 데이터베이스에 접근하여 실제 데이터를 조회 또는 조작하는 클래스 , Repository나 Mapper에 해당함

BO(Business Object) : 여러 DAO를 활용해 비즈니스 로직을 처리하는 클래스, Service에 해당함

 

Spring Singleton Pattern

싱글톤 패턴은 1개의 클래스당 1개의 객체만을 생성하여 사용하는 디자인 패턴이다. Spring에서는 스프링 컨테이너가 관리하는 객체인 Bean을 싱글톤 패턴으로 구현하여 제공한다.

Spring에서는 private 생성자나 static 메서드를 사용하지 않고도 해당 객체를 싱글 톤으로 관리하여 객체 지향적으로 개발을 할 수 있다.

 

자바로 싱글톤 패턴을 구현 시 단점

• private 생성자를 가지고 있어 상속이 불가능하다.
• 테스트하기 힘들다.
• 서버 환경에서는 싱글톤이 1개만 생성됨을 보장하지 못한다.

이러한 문제를 스프링 컨테이너를 통해 직접 싱글톤 객체를 생성하고 관리하는데, 다음과 같은 장점이 있다.

static 메서드나 private 생성자를 사용하지 않아 객체지향적 개발을 할 수 있다.

테스트 하기 편리하다.

디자인 패턴

1. 생성 패턴
   • 팩토리 패턴 : 객체를 생성하기 위한 디자인 패턴
   • 추상 팩토리 패턴 : 객체를 생성하는 팩토리를 생성하기 위한 디자인 패턴
   • 빌더 패턴 :상황에 따라 동적인 인자를 필요로 하는 객체를 생성하기 위한 디자인 패턴
   • 싱글톤 패턴 : 객체를 1개만 생성하여 항상 참조 가능하도록 고안된 디자인 패턴
2. 구조 패턴
   • 어댑터 패턴 :  호환성이 맞지 않는 두 클래스를 연결하여 사용하기 위한 디자인 패턴
   • 프록시 패턴 : 어떤 객체에 접근하기 위해 프록시 객체를 사용하는 디자인 패턴
   • 퍼사드 패턴 : 어떤 복합적인 기능에 대해 간략화된 인터페이스를 제공하는 디자인 패턴
3. 행위패턴
   • 전략 패턴 :  상황에 따라 다른 전략을 사용하기 위한 디자인 패턴
   • 옵저버 패턴 : 값을 관찰하여 빠르게 반영하기 위한 디자인 패턴
   • 커맨드 패턴 : 실행될 기능을 캡슐화하여 재사용성이 높은 클래스를 설계하기 위한 디자인 패턴

Spring filter와 Intercepter 차이

필터는 웹 컨테이너에서 관리하고 요청/응답이 조작 가능하다. 필터는 보안 관련 공통 작업을 할 때 사용하고, 모든 요청을 로깅 또는 감사한다.

인터셉터는 스프링 컨테이너에서 관리하고 요청/응답 조작이 불가능하다. 인터셉터는 인증/ 인가 등과 같은 공통 작업을 할 때 사용되고, Controller로 넘겨주는 정보의 가공을 담당한다. 또 API 호출에 대한 로깅 또는 감사를 한다.

 

Ioc Container

• Ioc Container는 객체의 생성과 관계 설정, 사용, 제거 등의 전체 라이프 사이클을 관리해주는 작업을 하는 컨테이너이다.
• Ioc Container의 대표적인 명세는 BeanFactory인데 요즘은 이를 상속하는 Application Context를 사용한다.
• Application Context는 BeanFactory의 기능뿐만 아니라, 메시지 다국화, 이벤트 발행 기능, 리소스 로딩 등의 여러 기능을 제공한다.

Spring Ioc Contaainer의 Bean 등록 방법에는 XML 설정 파일을 통해 Bean 등록, @Annotation을 통해 bean 등록하는 방법이 있다.

하지만 어노테이션 기반의 빈 등록 시에는 컴포넌트 스캔을 필요로 한다. 직접 등록해줄 수 있지만 스프링 부트에서는 컴포넌트 스캔을 자동으로 해준다.

• @Configuration : 스프링 설정으로 사용하겠다는 의미
• @EnableAutoConfiguration : 지정해둔 설정 값들을 자동으로 설정하는 기능을 켠다는 의미
• @ComponentScan,@Componentm@Configuration 붙은 클래스를 Bean으로 등록

컴포넌트 스캔

컴포넌트 스캔은 컴포넌트 대상을 가져와 Bean으로 등록하기 위해 찾는 과정이다.

 

Spring AOP

• Spring AOP는 핵심적인 관심사항과 공통 관심사항으로 분리시키고 각각을 모듈화 하는 것이다.

 

AOP과정

• 다이내믹 프록시 객체의 생성 요청
• 포인트 컷을 통해 부가 기능 대상 여부 확인
• 어드바이스로 부가 기능 적용
• 실제 기능 처리

Spring AOP는 프록시를 이용하였으며 자바의 기본 JDK와 스프링 컨테이너 외에는 특별한 기술이나 환경을 필요로 하지 않는다.

하지만 이러한 프록시 방법은 반드시 스프링 컨테이너가 필요하여 부가기능의 처리가 어려운 단점이 있어서 바이트를 조작하는 AOP가 등장하게 된 것이다.

 

Aspect AOP

Spring AOP 대신 다른 AOP 프레임워크 중 하나인 AspectJ는 프록시를 이용하지 않았다. 대신 CGlib라는 바이트 조작 라이브러리를 사용하여 타깃 오브젝트의 바이트를 고쳐서 부가기능을 직업 넣어주는 방법을 사용했다.

우리가 만든 코드에는 부가 기능이 분리되어 있지만 바이트 코드에서는 핵심 기능과 부가 기능이 섞여있는 구조이다.

AspectJ가 프락시를 사용하지 않고 CGlib를 이용한 복잡한 바이트 조작 방법을 사용하는 이유는 2가지가 있다.

• 바이트 코드를 조작하면 Spring과 같은 컨테이너의 도움이 필요 없다.
• 프록시 방식보다 훨씬 강력하고 유연한 AOP를 제공할 수 있다.

Spring WebFlux

Spring WebFlux란 Blocking+ 동기 방식으로 동작하는 Spring MVC의 한계점을 극복하기 위해 등장하였다.

기존의 Spring MVC에서는 HTTP 요청 등을 큐에 넣어두고, 멀티스레드 기반으로 동작했다. 하지만 이러한 방식은 응답성이 상대적으로 떨어지기 때문에 비동기적으로 요청을 처리하기 위한 방법이 필요하게 되었고, 리엑티브 프로그래밍을 통해 비동기 데이터의 스트림으로 non_blocking 애플리케이션을 개발하기 위해 등장한 프레임워크이다.