기술 면접 - SPRING

1. Spring Framework

자바(JAVA) 엔터프라이즈 개발을 위한 "오픈소스(Open Source)" 애플리케이션 프레임워크(Framework)

특징

• 경걍 컨테이너로서 자바 객체를 직접 관리
  • 각각의 객체 생성, 소멸과 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다
• 스프링은 POJO 방식의 프레임워크
  • 구현을 위해 특정한 인터페이스를 구현하거나 상속을 받을 필요가 없어 기존에 존재하는 라이브러리 등을 지원하기에 용이하고 객체가 가벼움
• IOC를 지원함
  • 컨트롤의 제어권이 사용자가 아니라 프레임워크에 있기 때문에 필요에따라 스프링에서 사용자의 코드를 호출함
• DI를 지원함
  • 각각의 계층이나 서비스들 간에 의존성이 존재할 경우 프레임워크가 서로를 연결시켜 준다
• AOP를 지원한다
  • 트랜잭션이나, 로깅, 보안과 같이 여러 모듈에서 공통적으로 사용하는 기능의 경우 해당 기능을 분리하여 관리할 수 있음
• 영속성 관련 다양한 지원
  • hibernate 등 데이터베이스 처리 라이브러리와 연결할 수 있는 인터페이스를 제공함
• PSA(Portable Service Abstraction)
  • 추상화 계층을 사용해서 특정 기술을 내부에 숨기고 개발자에게 편의성을 제공하며 제공되는 기술을 다른 기술 스택으로 간편하게 바꿀 수 있는 확장성을 갖고 있는 것

---

2. IOC 컨테이너

• IoC 컨테이너란 Bean 즉, IoC Container에서 관리하는 객체의 생성과 관계설정, 사용, 제거 등의 전체 라이프 사이클을 관리해주는 작업을 하는 컨테이너를 IoC 컨테이너라고 부릅니다.
• 대표적으로 ApplicationContext 인터페이스가 있음

 

---

3. BEAN 등록 방법

• xml 설정 파일을 이용한 등록
• 어노테이션을 이용한 등록 -> component scan 필요

---

4. SPRING LEGACY vs SPRING BOOT

• 가장 큰 차이점은 Auto Configuration

Spring MVC 프로젝트를 Spring Framework 기반으로 구성을 한다면, 컴포넌트 스캔, bean 설정, Dispatcher Servlet 설정, View Resolver, JDBC 설정 등의 다양한 설정을 해야하지만 이를 Spring Boot 기반으로 구성함으로써 초기 개발 환경 세팅에 걸리는 리소스를 많이 아낄 수 있음

---

5. BEAN 주입 방법

1. @Autowired 어노테이션으로 필드에 주입
2. 생성자를 통한 주입
3. setter를 통한 주입

---

6. AOP

• 기존의 OOP에서 기능별로 클래스를 분리했지만 여전히 로깅, 트랜잭션, 보안, 자원 해제, 성능 테스트 등 공통적으로 반복되는 중복코드가 여전히 발생하는 단점을 해결하고자 나온 방식
• 개발 코드에서는 비즈니스 로직에 집중하고 실행시에 비즈니스 로직 앞, 뒤 등 원하는 지점에 해당 공통 관심사를 수행할 수 있게 함으로서 중복코드를 줄일 수 있는 방식

---

7. DI

• 기존처럼 개발코드 부분에서 객체를 생성하지 않고, 팩토리 패턴처럼 객체의 생성과, 데이터를 주입만 담당하는 패곹리에 해당 하는 별도의 공간에서 객체를 생성하고 데이터 간의 의존성을 주입해 개발코드에서는 이를 가져다씀으로서 의존성을 줄이는 방식
• 객체가 직접 의존하고 있는 객체를 생성하거나 검색할 필요가 없어지므로 코드의 관리가 쉬워짐

---

8. IOC

• 인스턴스의 생성부터 소멸까지 개발자가 아닌 컨테이너가 대신 관리해주는 것

---

9. DTO, DAO, VO, BO

• DTO(Data Transfer Object)
  • 데이터를 주고 받기 위해 사용하는 클래스
• DAO(Data Access Object)
  • DB에 접근하여 실제 데이터를 조회 또는 조작하는 클래스, Repository
• VO(Value Object)
  • 실제 데이터만을 저장하는 클래스
• BO(Business Object)
  • 여러 DAO를 활용해 비즈니스 로직을 처리하는 클래스, Service

---

10. 필터 vs 인터셉터 vs AOP

공통부분을 빼서 따로 관리한다는 측면은 같다

• 필터
  • 서블릿 필터는 DispatcherServlet 이전에 실행이 되는데 필터가 동작하도록 지정된 자원의 앞단에서 요청내용을 변경하거나, 여러가지 체크를 수행할 수 있다.
• 인터셉터
  • 필터는 스프링 컨텍스트 외부에 존재하여 스프링과 무관한 자원에 대해 동작한다.
  • 하지만 인터셉터는 스프링의 DistpatcherServlet이 컨트롤러를 호출하기 전, 후로 끼어들기 때문에 스프링 컨텍스트(Context, 영역) 내부에서 Controller(Handler)에 관한 요청과 응답에 대해 처리한다.
• AOP
  • Interceptor나 Filter와는 달리 메소드 전후의 지점에 자유롭게 설정이 가능하다.
  • 객체 지향의 프로그래밍을 했을 때 중복을 줄일 수 없는 부분을 줄이기 위해 종단면(관점)에서 바라보고 처리한다.

---

11. SPRING MVC(***)

• Mvc 패턴의 처리 과정

1. 클라이언트(Client)가 서버에 어떤 요청(Request)을 한다면 스프링에서 제공하는 DispatcherServlet 이라는 클래스(일종의 front controller)가 요청을 가로챈다.
2. 요청을 가로챈 DispatcherServlet은 HandlerMapping(URL 분석등..)에게 어떤 컨트롤러에게 요청을 위임하면 좋을지 물어본다.
3. 요청에 매핑된 컨트롤러가 있다면 @RequestMapping을 통하여 요청을 처리할 메서드에 도달한다.
4. 컨트롤러에서는 해당 요청을 처리할 Service를 주입(DI)받아 비즈니스로직을 Service에게 위임한다.
5. Service에서는 요청에 필요한 작업 대부분(코딩)을 담당하며 데이터베이스에 접근이 필요하면 DAO를 주입받아 DB처리는 DAO에게 위임한다.
6. DAO는 mybatis(또는 hibernate등) 설정을 이용해서 SQL 쿼리를 날려 DB에 저장되어있는 정보를 받아 서비스에게 다시 돌려준다.(이 때, 보통 Request와 함께 날아온 DTO 객체(@RequestParam, @RequestBody, ...)로 부터 DB 조회에 필요한 데이터를 받아와 쿼리를 만들어 보내고, 결과로 받은 Entity 객체를 가지고 Response에 필요한 DTO객체로 변환한다.)
7. 모든 비즈니스 로직을 끝낸 서비스가 결과물을 컨트롤러에게 넘긴다.
8. 결과물을 받은 컨트롤러는 필요에 따라 Model객체에 결과물 넣거나, 어떤 view(jsp)파일을 보여줄 것인지등의 정보를 담아 DispatcherServlet에게 보낸다.
9. DispatcherServlet은 ViewResolver에게 받은 뷰의 대한 정보를 넘긴다.
10. ViewResolver는 해당 JSP를 찾아서(응답할 View를 찾음) DispatcherServlet에게 알려준다.
11. DispatcherServlet은 응답할 View에게 Render를 지시하고 View는 응답 로직을 처리한다.
12. 결과적으로 DispatcherServlet이 클라이언트에게 렌더링된 View를 응답한다.

---

12. MVC 1, MVC2

mvc1

• 웹 브라우저의 요청을 jsp가 처리, jsp가 컨트롤러와 뷰 기능을 모두 담당
• 개발이 쉽지만, 유지 보수가 어려움

mvc2

• 웹 브라우저 요청을 서블릿이 처리함
• 구조가 복잡하지만 유지보수, 확장에 용이하다

---

13. 스프링 시큐리티

참조 링크

Spring Boot + Spring Security + JWT + Redis + JPA

14. 메이븐, 그래들

참조 링크

Maven vs Gradle

15. JPA 개념

참조 링크

Spring Boot + Spring Security + JWT + Redis + JPA

---

16. JPA 영속성 컨텍스트

영속성 컨텍스트는 엔티티를 영구 저장하는 환경을 의미합니다.

영속성 컨텍스트를 쓰는 이유는 1차 캐시, 동일성 보장, 쓰기 지연, 변경감지(Dirty checking), 지연로딩이 있습니다.

• 1차 캐시: 조회가 가능하며 1차 캐시에 없으면 DB에서 조회하여 1차 캐시에 올려 놓습니다.
• 동일성 보장: 동일성 비교가 가능합니다.(==)
• 쓰기 지연: 트랜잭션을 지원하는 쓰기 지연이 가능하며 트랜잭션 커밋하기 전까지 SQL을 바로 보내지 않고 모아서 보낼 수 있습니다.
• 변경 감지(Dirty checking): 스냅샷을 1차 캐시에 들어온 데이터를 찍습니다. commit 되는 시점에 Entity와 스냅샷과 비교하여 update SQL을 생성합니다.
• 지연 로딩: 엔티티에서 해당 엔티티를 불러올 때 그 때 SQL을 날려 해당 데이터를 가져옵니다.

---

17. JPA Propagation

JPA Propagation은 트랜잭션 동작 도중 다른 트랜잭션을 호출(실행)하는 상황에 선택할 수 있는 옵션입니다.

@Transactional의 propagation 속성을 통해 피호출 트랜잭션의 입장에서는 호출한 쪽의 트랜잭션을 그대로 사용할 수도 있고, 새롭게 트랜잭션을 생성할 수도 있습니다.

REQUIRED(디폴트): 부모 트랜잭션 내에서 실행하며 부모 트랜잭션이 없을 경우 새로운 트랜잭션을 생성합니다.

---

18. JPA 사용 이유

JPA를 사용하는 이유는 객체지향 프레임워크이기 때문입니다. JPA를 사용하면 비즈니스 로직이 RDBMS에 의존하는 것이 아니라, 자바 코드로 표현될 수 있기 때문입니다. 그로 인해서 생산성이 높아진다고 볼 수 있습니다.

또, JPA는 JPQL로 SQL을 추상화하기 때문에 RDBMS Vendor에 관계없이 동일한 쿼리를 작성해서 같은 동작을 기대할 수 있다는 장점도 가지고 있습니다. 이는 database dialect를 지원하기 때문에 가지는 장점입니다.