[Spring] Spring Boot 장점 및 동작

MVC 아키텍쳐 패턴 / 3-Layered 아키텍쳐 패턴

Spring Boot의 의의: (1) 의존성 관리 + (2) 자동 설정

Spring Boot는 복잡한 설정을 최소화하고 개발자가 핵심 비즈니스 로직에 집중할 수 있도록 설계된 프레임워크이다. 이는 React의 CRA(Create-React-App)와 비슷한 역할을 하며, 주로 다음 두 가지 기능에 중접을 둔다.

 

1. 의존성 관리:

• spring-boot-starter-web: 웹 애플리케이션 개발을 위한 모든 기능을 제공, 내장된 Tomcat 서버와 함께 자동 설정을 제공
• spring-boot-starter-security: 인증, 인가, 권한 라이브러리
• spring-boot-starter-data-jpa: JPA 및 Hibernate 관련 의존성
• spring-boot-starter-jdbc: HikariCP 커넥션 풀을 사용한 JDBC 기능 제공

2. 자동 설정:

• Spring Boot는 대부분의 설정을 자동으로 처리하여 개발자가 신경 쓸 부분을 줄여준다.
• 주요 자동 설정:
  • @SpringBootApplication: Spring Boot에 필요한 모든 것을 세팅 및 기본 설정
    • @SpringBootConfiguration: @Configuration을 통해 추가 @Bean 등록 가능
    • @EnableAutoConfiguration: 사전 정의된 라이브러리들에 대한 기본(Default) 설정 값
    • @ComponentScan: XML이 아닌 @Controller 등 어노테이션 기반 Bean 수집 규칙 정의

Spring vs Spring Boot

Spring과 Spring Boot의 차이는 전통적인 Spring Framework의 설정과 Spring Boot의 간편한 설정 간의 차이에서 발생한다.

 

1. Spring

• WAR (Web Application Archive) 파일로 외부 WAS(Tomcat 등)에 배포된다.
• 별도의 Tomcat과 같은 서버에 WAR 파일을 배포하고 실행해야 하며, 설정이 복잡하다.

2. Spring Boot:

• JAR (Java Archive) 파일로 바로 실행 가능한 애플리케이션을 제공한다.
• 내장된 Tomcat 서버와 함께 실행되며, 별도의 서버 설정 없이 애플리케이션을 바로 실행할 수 있다.
• Spring Boot는 JAR 파일 실행과 동시에 내장된 Tomcat 서버를 시작하며, 환경 설정의 편리함을 제공한다.

WAR와 JAR에 대해선 지난 포스팅에서도 언급했었다. 해당 글을 참고하자 (https://1000sang-dev.tistory.com/55)

Spring의 MVC 아키텍쳐 패턴

Spring은 두 가지 주요 아키텍처 패턴으로 구성된다.

 

1. MVC 패턴(Model-View-Controller)

2. 3-Layered 패턴

Spring 구조 1) MVC  아키텍쳐 패턴 : 요청에 따른 반환을 위한 로직

https://1000sang-dev.tistory.com/55

[Spring] Spring MVC 원리

이전 포스팅에서 이미 다뤘던 내용이니 이번 포스팅에선 간단하게 요약하자면

• Front Controller (DispatcherServelt): 클라이언트 요청을 받아 적절한 Controller로 전달하고 View와 Model을 반환받아 처리한다.
• Controller: 클라이언트 요청을 처리하고 필요한 비즈니스 로직을 수행하여 결과를 Model에 담는다.
• View: 최종적으로 클라이언트에게 반환되는 페이지(HTML 또는 JSON 등)를 생성한다.

 

MVC 아키텍쳐 동작 흐름

1. DispatcherServlet: 클라이언트의 요청을 받아 적절한 Controller에 전달한다.

2. Controller: 비즈니스 로직을 처리한 후, 결과 데이터를 Model에 담고 View이름을 반환한다

3. ViewResolver: Controller에서 반환된 View 이름을 기반으로 해당 페이지를 찾아서 반환한다.

4. View: 최종 결과 페이지를 생성하여 클라이언트에게 응답한다.

Spring MVC 아키텍쳐 패턴 상세 설명

Spring은 Java 기반의 웹 애플리케이션 프레임워크이며, Java 기반 WAS인 Tomcat을 기반으로 동작한다. Tomcat은 Servlet Container로, Java 기반의 웹 애플리케이션을 구동하는 표준 기술인 Servlet을 통해 동작한다.

 

Front Controller 이전의 Servlet: Java EE 시절

과거 Java EE에서는 요청되는 URL마다 각기 다른 Servlet을 만들어 개발했다. 예시로:

• GET /hello 요청은 HelloGetServlet이 처리.
• POST /hello 요청은 HelloPostServlet이 처리.

각 URL마다 별도의 Servlet을 만들어 처리해야 했기 때문에 복잡성이 증가했다.

 

Front Controller가 적용된 Servlet: 현재 Spring

Spring에서는 단일 Servlet인 DispatcherServlet을 이용해 모든 요청을 처리한다.

DispatcherServlet은 일종의 FrontController 역할을 하여, 각 URL마다 다른 Servlet을 생성할 필요 없이 하나의 Controller에서 URL을 중앙 관리하고 처리할 수 있다.

• GET /hello → DispatcherServlet → HelloGetController
• POST /hello → DispatcherServlet → HelloPostController

이 패턴을 사용하면 모든 URL 처리가 중앙에서 이루어지기 때문에 개발의 복잡성이 크게 줄어든다.

중앙화 = 중앙처리 + 중앙관리

중앙화는 Controller 호출과 View 생성을 중앙에서 관리함으로써 시스템을 보다 일관성 있게 유지하고 처리속도를 높인다.

 

1. Contoller 호출의 중앙화:

• HandlerMapping: 요청 URL에 맞는 Controller를 찾아준다.
• HandlerAdapter: 찾은 Controller를 실행하여 결과를 반환한다.

2.  View 생성의 중앙화:

• ViewResolver: Contoller가 반환한 View 이름에 맞는 템플릿을 찾아 View를 생성한다.
• View: Model 데이터를 템플릿과 합쳐 최종 결과를 클라이언트에게 반환한다.

Spring - Front Controller 상세 흐름

Spring의 Front Controller 패턴은 모든 요청을 하나의 중앙화된 컨트롤러인 DispatcherServlet이 처리하는 구조이다. 이 과정에서 Spring의 컨테이너와 Tomcat과 같은 Servlet 컨테이너가 함께 작동하여 요청을 처리하고, 적절한 Controller를 찾아 응답을 생성한다.

 

1. EC2 서버에서 Tomcat 구동 시 2개의 컨테이너 생성

• Servlet Container(ServletContext): Tomcat이 처음 구동되면, 가장 먼저 ServletContext가 생성된다. 이는 웹 애플리케이션 전체의 환경 설정과 관련된 정보를 저장하는 컨텍스트이다.
• Spring Container(ApplicationContext): ServletContextListener가 실행된 후, Spring의 ApplicationContext가 생성된다. ApplicationContext는 Spring의 IoC(Inversion of Control) 컨테이너로, Bean을 관리한다. Spring은 두 가지 계층으로 구성된다.
  • Servlet WebApplicationContext: @Controller, HandlerMapping, ViewResolver등의 웹 관련 Bean들이 포함된 컨텍스트이다. 이를 Presentation Layer라고 부를 수 있다.
  • Root WebApplicationContext: @Service, @Repository, @Component 등의 비즈니스 로직과 데이터 액세스 관련 Bean들이 포함된 컨텍스트이다. 이를 Business Layer 또는 Data Access Layer라고 부른다.

2. Tomcat이 클라이언트의 요청을 받음

• 클라이언트의 요청이 들어오면, Tomcat은 요청된 URL에 맞는 정적 리소스를 확인한다. 만약 정적 리소스가 없다면 이 요청을 Servlet Container가 처리한다.

3. Servlet Container가 요청을 받아 Servlet에 할당

• Spring에서는 요청을 처리하기 위해 단일 DispatcherServlet을 사용한다. 이 Servleet이 모든 요청을 중앙에서 처리한다.

4. DispatcherServlet이 요청을 처리

• DispatcherServlet은 Front Controller로서, 요청된 URL에 맞는 적절한 Controller를 찾아 실행한다.

5. Contoller 호출과 View 생성의 중앙화

 

(1). Contoller 호출의 중앙화:

• HandlerMapping: 요청된 URL에 맞는 Controller를 찾아주는 역할을 한다.
• HandlerAdapter: 찾은 Contoller를 실행하여, 결과로 Model과 View 이름을 반환한다. 이 과정에서 ModelAanddView 객체나 Model과 String으로 이름을 반환할 수 있다.

@RequestMapping(method = RequestMethod.GET, value = "/")
public ModelAndView index() {
    ModelAndView mav = new ModelAndView();
    mav.addObject("name", "Aaron");
    mav.addObject("age", 10);
    mav.setViewName("index.html");
    return mav;
}

 

또는 최근 Strping 방식인 Model과 View 이름을 반환하는 방법:

@RequestMapping(method = RequestMethod.GET, value = "/")
public String index(Model model) {
    model.addAttribute("name", "Aaron");
    model.addAttribute("age", 10);
    return "index.html";
}

 

(2). View 생성의 중앙화:

• ViewResolver: Controller가 반환한 View 이름에 맞는 템플릿 파일을 찾는다.
• View: 찾은 템플릿 파일에 Model 데이터를 합쳐 최종적으로 클라이언트에게 반환할 View를 생성한다.
• Thymeleaf: Spring에서 기본적으로 사용하는 서버사이드 템플릿 엔진으로, HTML 형태로 프로토 타입을 확인할 수 있다.

6. 최종적으로 View가 클라이언트에게 반환

• 최종적으로 View 템플릿이 렌더링되고, 생성된 결과물이 클라이언트에게 반환된다. 이 과정에서 Thymeleaf와 같은 서버사이드 템플릿 엔진이 사용될 수도 있으며, React나 Vue와 같은 클라이언트 사이드 템플릿 엔진을 사용할 수도 있다.

Spring 구조 2) 3-Layered 아키텍처 패턴: 상세 구현 시 관심사 분리

Spring은 딱 2개의 아키텍처 패턴으로 구성되어 있다: MVC 아키텍처 패턴 + 3 계층 아키텍처 패턴

 

이 패턴의 핵심은 애플리케이션의 Presentation, Business, Data Access 계층으로 역할을 분리하는 것이다.

1. Presentation Layer: 사용자 인터페이스와 관련된 부분으로, 클라이언트 요청을 처리하고 화면을 생성하여 반환하는 역할. Spring MVC의 @Controller가 여기에 해당한다.
2. Business Layer: 비즈니스 로직을 담당하는 계층이다. @Service는 클라이언트의 요청에 따라 필요한 데이터를 가공하고, 이를 Presentation Layer에 전달하는 역할을한다. "Spring 프레임워크는 개발자에게 "비즈니스 구현" 에만 신경쓰도록한다"
3. Data Access Layer: 애플리케이션의 영속성을 유지하는 계층으로, 데이터베이스와 상호작용하여 CRUD 작업을 처리한다 @Repository가 여기에 해당하며, 비즈니스 계층에서 요청한 데이터를 조회하거나 저장하는 역할을 한다.
   • DAO(Data Access Object)와 유사한 개념으로, 데이터베이스와 직결된 CRUD 함수들이 포함된다. 예를 들어 EntityManager를 통해 직접 데이터베이스와 소통할 수 있다.

public interface UserDao {
    void create(User user);
    User read(Long id);
    void update(User user);
    void delete(String userName);
}

• @Repository는 DAO를 캡슐화하여 더 추상화된 방식으로 사용된다. 필요에 따라 DAO의 일부 기능만 사용할 수 있도록 제공한다.

public interface UserRepository {
    User get(Long id); // 필요한 함수만 구현할 수 있음.
    // void add(User user);
    // void update(User user);
    // void remove(User user);
}

DAO 와 Repository 차이점

DAO와 Repository 패턴은 유사하지만 다르다. DAO는 데이터베이스와 직접적인 상호작용에 초점을 맞추고 Repository는 데이터 액세스 로직을 캡슐화하여 필요에 따라 특정 기능만 사용할 수 있도록 하는 방식이다. Spring에서는 이 두 개념이 혼용되어 사용되기도 하지만, Repository는 좀 더 고수준의 개념으로서 DAO를 내무적으로 사용할 수 있다.

참고: https://www.baeldung.com/java-dao-vs-repository

 

DTO (Data Transfer Object)와 VO (Value Object) 차이

• DTO: 데이터 전달 객체로, 데이터만을 담고 있는 객체이다. 주로 Getter와 Setter 메서드만 포함하며, 여러 계층 간의 데이터 이동을 위한 역할을 수행한다. 가변성을 가지며, 데이터가 여러 메서드와 객체들 사이를 전달하는 용도로 사용된다.
• VO: DTO에서 Setter 메서드를 제외한 불변 객체이다. DTO는 데이터를 변경할 수 있는 가변 객체지만, VO는 한 번 생성된 후 값이 변경되지 않는 불변 객체이다. MyBatis로 데이터베이스에서 읽어온 객체는 주로 VO로 처리된다.

예를 들어, DTO는 사용자가 요청한 데이터를 서버로 전달하거나, 서버에서 클라이언트로 전달할 때 사용된다. 반면에 VO는 데이터가 변경되지 않고 값으로만 의미를 가지는 경우에 사용된다.

 

---

ℹ️ 참고

[ASAC 6기 강의자료]

https://www.baeldung.com/java-dao-vs-repository