스프링 면접 리스트

devdo·2021년 12월 22일
1

기술면접

목록 보기
4/6

Servlet vs JSP

  • Servlet : 자바 언어로 웹 개발을 위해 만들어진 것으로, Container(ex. Tomcat)가 이해할 수 있게 구성된 순수 자바코드로만 이루어진 서버프로그램

  • JSP : html 기반에 JAVA 코드를 블록화하여 삽입한 것으로 Servlet을 좀 더 쉽게 접근할 수 있도록 만들어 진 도구


POJO란?

Plain Old Java Object. 간단히 '포조' 라는 말 그대로 해석하며 오래된(순수한) 방식의 자바 오브젝트로서 J2EE등의 중량 프레임워크들을 사용하면서 해당 프레임워크에 종속된 무거운 객체를 만들게 된 것에 반발하여 특정 자바 모델이나 기능, 프레임워크 등을 따르지 않는 자바 오브젝트를 지칭하는 말

참조) https://yoo11052.tistory.com/133


스프링이란?

자바로 된 오픈소스 프레임워크로 자바SE로 된 자바 객체(POJO)를 자바EE에 의존적이지 않게 연결해주는 역할함. Bean Factory, ApplicationContext 라고 불리기도 함.
자바 개발을 위한 프레임워크로 종속 객체를 생성해주고, 조립해주는 도구

더 많은 특징들을 정리하면,

a. 경량 컨테이너로서 자바 객체를 직접 관리.

각각의 객체 생성, 소멸과 같은 라이프 사이클을 관리하며 스프링으로부터 필요한 객체를 얻어올 수 있다.

b. 스프링은 POJO(Plain Old Java Object) 방식의 프레임워크.

일반적인 J2EE 프레임워크에 비해 구현을 위해 특정한 인터페이스를 구현하거나 상속을 받을 필요가 없이 기존에 존재하는 라이브러리 등을 지원하기에 용이하고 객체가 가볍다.

c. 스프링은 제어의 역행(IoC : Inversion of Control)을 지원.

컨트롤의 제어권이 사용자가 아니라 프레임워크에 있어서 필요에 따라 스프링에서 사용자의 코드를 호출한다.

d. 스프링은 의존성 주입(DI : Dependency Injection)을 지원

각각의 계층이나 서비스들 간에 의존성이 존재할 경우 프레임워크가 DI(의존관계 주입)하여 서로 연결시켜준다.

  • 의존성 주입 원칙
    1) 상위 모듈은 하위 모듈에서 어떠한 것도 가져오지 않아야 한다.
    2) 상위, 하위 둘다 추상화에 의존해야 하며, 이때 추상화는 세부 사항에 의존하지 말아야 한다.

e. 스프링은 관점 지향 프로그래밍(AOP : Aspect-Oriented Programming)을 지원

트랜잭션이나 로깅, 보안과 같이 여러 모듈에서 공통적으로 사용하는 기능의 경우 해당 기능을 분리하여 관리할 수 있다.

f. 스프링은 영속성과 관련된 다양한 서비스를 지원

iBatis나 Hibernate 등 이미 완성도가 높은 데이터베이스 처리 라이브러리와 연결할 수 있는 인터페이스를 제공한다.

g. 스프링은 확장성이 높음.

스프링 프레임워크에 통합하기 위해 간단하게 기존 라이브러리를 감싸는 정도로 스프링에서 사용이 가능하기 때문에 수많은 라이브러리가

이미 스프링에서 지원되고 있고 스프링에서 사용되는 라이브러리를 별도로 분리하기도 용이하다.


스프링 Bean 생성 과정

객체 생성 -> 의존 설정 -> 초기화 -> 사용 -> 소멸 과정의 생명 주기를 가지고 있습니다. Bean은 스프링 컨테이너에 의해 생명 주기를 관리하며 빈 초기화방법은 @PostConstruct 를 빈 소멸에서는 @PreDestory 를 사용합니다.

생성한 스프링 빈을 등록할 때는 ComponentScan을 이용하거나 @Configuration의 @Bean을 사용하여 빈 설정파일에 직접 빈을 등록할 수 있습니다.


스프링 Bean Scope

빈 스코프는 빈이 존재할 수 있는 범위를 뜻하며 싱글톤, 프로토타입, request, session, application 등이 있습니다.

싱글톤은 기본 스코프로 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 스코프입니다.

프로토타입은 빈의 생성과 의존관계 주입까지만 관여하고 더는 관리하지 않는 매우 짧은 범위의 스코프입니다.

request는 웹 요청이 들어오고 나갈때 까지 유지하는 스코프, session은 웹 세션이 생성, 종료할 때까지, application은 웹 서블릿 컨텍스트와 같은 범위로 유지하는 스코프입니다.


스프링 MVC

객체지향프로그래밍에서, MVC란 사용자 인터페이스를 성공적이며 효과적으로 데이터 모델에 관련 시키기 위한 방법론 또는 설계 방식중 하나.

MVC 패턴은 목적 코드의 재사용에 유용한 것은 물론, 사용자 인터페이스와 응용프로그램 개발에 소요되는 시간을 현저하게 줄여주는 형식이라고 많은 개발자들이 평가하고 있다.

MVC 구성요소

Model - 소프트웨어 응용과 그와 관련된 고급 클래스 내의 논리적 데이터 기반 구조를 표현. 이 목적 모형은 사용자 인터페이스에 관한 어떠한 정보도 가지고 있지 않다.

View - 사용자 인터페이스 내의 구성요소들을 표현(사용자에게 보여지는 화면)

Controller - Model과 View를 연결하고 있는 클래스를 대표, Model과 View 내의 클래스들 간 정보 교환하는데 사용.


MVC1과 MVC2 패턴의 차이

Model1

:JSP, 자바빈 또는 서비스 클래스

JSP페이지 내에 로직 처리를 하기 위해 자바 코드가 출력을 위한 코드와 함께 삽입된다. JSP페이지는 요청이 오면 직접 자바빈이나 클래스를 이용하여 작업을 처리하고 처리한 정보를 클라이언트에 출력한다.

장점 : 구조가 단순하다

단점 : 출력을 위한 HTML 코드와 로직 처리를 위한 Java코드가 삽입되어 복잡하고, 유지보수가 어려워진다.

Model2

: 서플릿, JSP, 자바빈 혹은 서비스 클래스

모든 처리를 JSP가 담당하는 것이아니라 JSP 페이지와 서블릿 그리고 로직을 위한 클래스가 나뉘어 클라이언트의 요청을 처리한다.

클라이언트에서 요청이 오면 처리할 모델을 클래스 또는 자바 빈이 담당하고 요청결과는 뷰(JSP), 흐름 제어는 Controller인 서블릿이 담당한다.

사실 MVC 패턴이란 Model2 구조를 도입한 구조


Spring에서 DI란?

DI는 Dependency Injection(의존성 주입)의 약자로, 객체들 간의 의존성을 줄이기 위해 사용되는 Spring의 IOC 컨테이너의 구체적인 구현 방식.

DI는 기존처럼 개발코드 부분에서 객체를 생성하는 것이 아니라, 팩토리 패턴처럼 객체의 생성과, 데이터를 주입만 담당하는 Factory에 해당 하는 별도의 공간에서 객체를 생성(관심사 분리)하고 데이터간의 의존성을 주입해 개발코드에서는 이를 가져다 씀으로서 의존성을 줄이는 방식. 이때,

Factory 패턴의 Factory Class의 역할을 스프링의 환경설정 파일(Config)이 담당.

따로 분리된 설정 파일(Config)에 객체간의 의존관계를 설정함으로써 외부 Assembler가 객체간의 의존 관계를 정의하게 되며, 객체는 직접 의존하고 있는 객체를 생성하거나 검색할 필요가 없어지므로 코드의 관리가 쉬워진다.

DI 방식 3가지

1) 필드 주입 - @Autowired를 사용하는데 외부에서 변경이 불가능하여 테스트하기 힘듭니다. DI 프레임워크 없이는 동작이 불가능하여, 주로 애플리케이션과 관계없는 테스트코드나 @Configuration 같은 스프링 설정 목적으로 사용합니다.
2) Setter 메서드 주입 - 선택, 변경 가능성이 있는 의존관계에 사용되며 스프링 빈을 선택적으로 등록이 가능합니다.
3) 생성자 주입 - 생성자 호출시점에 딱 1번만 호출되는 것을 보장하며, 불변, 필수 의존관계에 사용합니다. @RequiredArgConstrctor를 사용합니다.


Spring의 AOP란?

AOP는 Aspect Oriented Programming 관점 지향 프로그래밍의 약자로, 기존의 OOP(객체 지향 프로그래밍)에서 기능별로 class를 분리했음에도 불구하고, 여전히 로그, 트랜잭션, 자원해제, 성능테스트 메서드 처럼 공통적으로 반복되는 중복코드가 여전히 발생하는 단점을 해결하고자 나온 방식

이러한 공통 코드를 "횡단 관심사"라 표현하며 개발코드에서는 비지니스 로직에 집중하고 실행시에 비지니스 로직 앞, 뒤 등 원하는 지점에 해당 공통 관심사를 수행할 수 있게 함으로서 중복 코드를 줄일 수 있는 방식이다.


스프링 MVC 구조 처리 과정을 설명하라.

1. DispatcherServlet : 어플리케이션으로 들어오는 모든 Request를 받는 관문이다. Request를 실제로 처리할 Controller 에게 전달하고 그 결과값을 받아서 View에게 전달하여 적절한 응답등 생성할 수 있도록 흐름을 제어한다.

2. HandlerMapping : Request URL 각각을 어떤 Controller 가 실제로 처리할 것인지 찾아주는 역할을 한다.

3. Controller : Request를 직접 처리한 후 그 결과를 다시 DispatcherServlet 에게 돌려준다.

4. ModelAndView : Controller가 처리한 결과와 그 결과를 보여줄 View에 관한 정보를 담고 있는 객체이다.

5. ViewResolver : View 관련 정보를 갖고 실제 View를 찾아주는 역할을 한다.

6. View : Controller가 처리한 결과값을 보여줄 View를 생성한다.


IOC란?

인스턴스 생성의 제어를 개발자 본인이 아닌 다른 누군가에게 반환해 준다는 개념으로 여기서 말하는 다른 누군가는 Servlet과 같은 bean을 관리해주는 컨테이너이다.

즉 IOC란 인스턴스의 생성부터 소멸까지 개발자가 아닌 컨테이너가 대신 관리해준다는 것이다.


Filter vs Interceptor vs AOP

Filter와 Interceptor는 실행되는 시점이 다르다.

Filter는 Web Application에 등록을 하고, Interceptor는 Spring의 Context에 등록을 한다.

컨트롤러에 들어가기 전에 작업을 처리하기 위해 사용할 수 있다는 공통점이 있지만 호출되는 시점이 다르다.

(Filter > Dispatcher servlet > Interceptor > AOP > Controller)

  1. Filter는 Dispatcher servlet의 앞단에서 정보를 처리하고, Interceptor는 Dispatcher servlet에서 Handler(Controller)로 가기 전에 정보를 처리한다.
  2. 또한 Filter는 J2EE 표준 스펙에 정의 되어 있는 기능이며, 인터셉터의 경우는 Spring Framework에서 자체적으로 제공하는 기능이라고 한다.

보통, 인코딩이나 보안 관련 처리와 같은 web app의 전역적으로 처리해야 하는 로직은 필터로.
클라이언트에서 들어오는 디테일한 처리(인증, 권한 등)에 대해서는 주로 인터셉터에서 처리한다.

  1. AOP는 정교하게 메서드단위로 공통관심사로 만들어 둘 수 있어 더 편하다.

DAO 와 DTO

DAO

Data Access Object의 약자로 간단히 Database의 data에 접근을 위한 객체입니다. Database에 접근을 하기위한 로직과 비즈니스 로직을 분리하기 위해서 사용을 합니다

DAO(Data Access Object)는 DB를 사용해 데이터를 조화하거나 조작하는 기능을 전담하도록 만든 오브젝트를 말한다.

DTO

DTO(Data Transfer Object)는 VO(Value Object)로 바꿔 말할 수 있는데 계층간 데이터 교환을 위한 자바빈즈를 말한다.여기서 말하는 계층간의 Controller, View, Business Layer, Persistent Layer를 말하며 각 계층간 데이터 교환을 위한 객체를 DTO 또는 VO라고 부릅니다. 그런데 VO는 DTO와 동일한 개념이지만 read only 속성을 가진다.


스프링 부트와 스프링의 차이

스프링 부트는 스프링 프레임워크르 사용하는 프로젝트를 간편하게 셋업할 수 있게한 스프링 버전이다(스프링 4버전). 독립 컨테이너에서 동작할 수 있기 때문에 embeded tomcat이 자동으로 실행된다.또 라이르러리 버전도 따로 할 필요없이 자동으로 관리해준다. 그외 war파일로 배포하지 않아도 내장 톰켓을 지원하기 때문에 jar로 패키징해서 웹 애플리케이션이 가능해졌다.


참고

profile
배운 것을 기록합니다.

0개의 댓글