지금까지 달려오면서 김영한님의 스프링 강의와 프로그래머스 데브코스에서 스프링을 많이 다뤄봤고 사용해보았다. 그럼에도 불구하고 "기본이 없다면 미래를 구축할 수 없다"는 말처럼, 기본부터 다시 차근차근 복습하며 미래를 위한 기초를 탄탄히 다져보려고 한다. 자세하게는 정리는 안할거고 간단하게 아 맞다! 이런거였지! 정도만 적을려고 한다.

프레임워크 vs 라이브러리

스프링에 대해 알려면 일단 프레임워크 와 라이브러리 의 차이를 정리해야한다.

• 프레임워크: 기본적으로 프로그래밍을 하기 위한 틀이나 구조를 제공
• 라이브러리: 단순 활용 가능한 도구들의 집합

❗️ 차이점을 간단하게 설명하면 흐름을 누가 가지고 있냐에 달려있다.

프레임워크 는 전체적인 흐름을 자체적으로 가지고 있기 때문에 개발자는 그 안에서 필요한 코드를 작성한다.
반면에, 라이브러리는 개발자가 전체적인 흐름을 가지고 있어 자신이 원하는 기능을 구현하고자 할 때, 가져다 사용이 가능하다.

간단하게 생각하면 프레임워크는 주도권이 프레임워크에게 있고 라이브러리는 주도권이 개발자한테 있다고 생각하면 된다.

📌 스프링(Spring)

• 자바 기반의 웹 어플리케이션을 개발하는데 사용하는 프레임워크

스프링(Spring) 특징

• 경량 컨테이너로서 자바 객체를 직접 관리하는 역할
  • 모든 객체의 라이프 사이클을 관리하며, 스프링에서 필요한 객체를 손쉽게 얻어올 수 있다.
• POJO(Plain Old Java Object)
  • 특별한 규약이나 프레임워크에 의존하지 않는 순수한 자바 객체로, 비즈니스 로직을 담는 데 사용
• IoC(Inversion Of Control) 지원 (제어의 역전)
  • 스프링이 흐름을 가지고 있어 스프링에서 사용자의 코드를 호출
• DI(Dependency Injection) 지원
  • 각각의 계층이나 서비스들 간, 의존성이 필요할 경우 스프링 프레임워크가 서로 연결 시켜줌
• AOP(Aspect-Oriented Programming) 지원
  • 트랜잭션, 로깅처럼 여러 모듈에서 공통적으로 사용되는 기능을 분리하여 관리 가능

🤔 DI(Dependency Injection)

사실 개인적으로 쉬우면서도 설명하기에는 어려운 개념이라고 생각한다. 의존성 주입은 스프링을 다룬다면 어딜 가든지 나오는 개념이다.

IoC (Inversion of Control)를 이해하면 DI가 왜 필요한지, 그리고 어떻게 동작하는지 더 명확히 알 수 있다.

IoC는 애플리케이션에서 객체를 생성하고 의존성을 설정하는 책임을 개발자가 아닌, 외부 컨테이너(스프링 컨테이너 등)에 맡기는 방식이다.

DI는 바로 이 IoC를 실제로 구현하는 방법 중 하나인데, 의존성을 주입받는 방식에는 생성자 주입, 세터(Setter) 주입, 필드 주입 등이 있다. 이 중에서 스프링에서는 생성자 주입을 선호하는 추세인데, 그 이유는 주입된 의존성이 불변성을 보장하고, 더 명확하게 의존성을 관리할 수 있기 때문이다.

필요로 하는 객체를 직접 생성하는 것이 아니라 외부에서 받는것

생성자 주입

public class YuhanService {
    private final YuhanRepository yuhanRepository;

    // 생성자 주입
    public YuhanService(YuhanRepository yuhanRepository) {
        this.yuhanRepository = yuhanRepository;
    }
}

세터(Setter) 주입

public class YuhanService {
    private YuhanRepository yuhanRepository;

    // 세터 주입
    public void setYuhanRepository(YuhanRepository yuhanRepository) {
        this.yuhanRepository = yuhanRepository;
    }
}

• 불변성 보장 불가

필드 주입

public class YuhanService {
    @Autowired
    private YuhanRepository yuhanRepository; 
}

롬복(Lombok)을 사용한다면 생성자 주입을 좀 더 쉽고 가독성있게 관리 가능하다.

@RequiredArgsConstructor
public class YuhanService {
    private final YuhanRepository yuhanRepository;
}

스프링 컨테이너(Spring Container)

스프링 컨테이너(Spring Container) 는 스프링의 핵심 컴포넌트다. 자바 객체의 생명 주기를 관리하며, 생성된 자바 객체들에게 추가적인 기능을 제공하는 역할을 한다.

간단하게 말하자면 스프링 컨테이너는 빈을 생성하고 관리

여기서 스프링에서는 자바 객체를 빈(Bean) 이라고 한다.

스프링 컨테이너는 BeanFactory , ApplicationContext 두 가지 인터페이스로 구현되어 있다.

BeanFactory는 스프링 컨테이너의 최상위 인터페이스고 빈을 등록, 생성, 조회 등의 빈을 관리하는 역할을 하며, getBean() 메서드를 통해 빈을 인스턴스화 할 수 있다. 하지만 ApplicationContext를 직접 사용하지 BeanFactory를 사용하는 경우는 별로 없다.

애플리케이션 컨텍스트(ApplicationContext)는 BeanFactory의 기능을 상속받아 제공한다.
따라서, 빈을 관리하고 검색하는 기능을 BeanFactory가 제공하고, 그 외의 부가 기능을 제공한다.

🤔 굳이 스프링 컨테이너가 필요할까? 그냥 new 로 객체를 생성하고 그러면 안되나?

• 객체를 생성할 때 new 생성자를 사용하면 객체 간 의존성이 높아지고, 이는 낮은 결합도와 높은 캡슐화를 추구하는 객체지향의 원칙에 맞지 않는다. 스프링 컨테이너는 객체 간 의존성을 낮추고, 느슨한 결합을 통해 캡슐화를 강화한다. 또한, 기존 방식에서는 새로운 기능 추가 시 수작업으로 수정해야 하지만, 스프링 컨테이너는 의존성을 인터페이스에만 의존하도록 설계하여 코드 변경을 최소화할 수 있다.

스프링 싱글톤(Spring Singleton)

스프링은 빈 생성시 디폴트로 싱글톤
컨테이너를 통해 직접 싱글톤 객체 생성 관리
요청이 들어올 때마다 매번 객체 생성 X -> 이미 만든 객체 사용 효율성 증가

스프링 빈 (Spring Bean)

• 스프링 Ioc 컨테이너에 의해 인스턴스화되고 관리되는 객체
• Spring 설정 파일(AppConfig)에 정의되거나 @Component, @Service, @Repository, @Controller 등의 어노테이션으로 표시
• XML, AppConfig(@Configuration) , 어노테이션으로 정의 가능

스프링 컨테이너가 생성한 객체

스프링 빈 생명 주기(Bean LifeCycle)

스프링 컨테이너 생성 -> Bean 생성 -> 의존성 주입 -> 초기화 콜백 -> Bean 사용 -> 소멸 전 콜백 -> 스프링 종료

스프링 VS 스프링부트

스프링부트는 스프링을 보다 간편하게 사용할 수 있도록 해주는 확장판이라고 생각하면 된다.

• 스프링 프레임워크는 기본적으로 웹 서버(톰캣)를 내장하지 않지만 스프링부트 (Spring Boot) 내장 톰캣을 기본으로 제공하여, 별도의 외부 서버 설정 없이 바로 실행 가능하다.

• 스프링 프레임워크는 의존성을 추가하기 위해서는 굉장히 복잡하다. 밑에를 보면 확실히 차이가 느껴질 것이다. 또한 configuration 설정도 스프링부트는 AutoConfiguration 을 제공하므로 더 편리하다.

스프링

<dependencies>
    <!-- Spring Web -->
    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-webmvc</artifactId>
        <version>5.3.9</version>
    </dependency>

    <!-- Spring Data JPA -->
    <dependency>
        <groupId>org.springframework.data</groupId>
        <artifactId>spring-data-jpa</artifactId>
        <version>2.5.4</version>
    </dependency>
 </dependencies>

스프링부트(Gradle)

dependencies {
    // Spring Boot Web
    implementation 'org.springframework.boot:spring-boot-starter-web'

    // Spring Boot Data JPA
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
}

디스패처 서블릿(DispatcherServlet)

HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 위임해주는 프론트 컨트롤러(Front Controller)

1. 클라이언트 요청 수신
   클라이언트가 웹 요청(HttpServletRequest)을 통해 애플리케이션에 접근하면, 이 요청이 DispatcherServlet으로 전달

2. HandlerMapping을 통한 Controller 매핑
   DispatcherServlet은 요청 URL과 기타 정보를 바탕으로, 요청을 처리할 적절한 Controller(Handler)를 찾기 위해 HandlerMapping에 요청을 위임

3. HandlerAdapter 선택
   찾은 Controller를 실행할 수 있도록, DispatcherServlet은 해당 Controller를 처리할 수 있는 HandlerAdapter를 결정

4. 비즈니스 로직 실행 요청
   DispatcherServlet은 선택된 HandlerAdapter에게 Controller의 비즈니스 로직을 실행하도록 요청

5. Controller 실행 및 결과 반환
   HandlerAdapter는 Controller의 메소드를 호출하여 비즈니스 로직을 수행Controller는 처리 결과를 Model 객체에 담고, 어떤 View를 사용할지 논리적인 이름을 함께 반환

• Model: 비즈니스 로직 실행 결과로 생성된 데이터
• View : 클라이언트에게 보여줄 화면(View) 파일의 이름

6. ViewResolver를 통한 View 결정
   DispatcherServlet은 반환받은 View 이름을 기반으로 ViewResolver에게 실제 View 객체를 결정하도록 요청

7. 최종 View 객체에 Model 전달
   ViewResolver가 반환한 View 객체에 Model 데이터를 함께 전달하면서, DispatcherServlet은 최종 화면 렌더링을 의뢰

8. 렌더링 및 응답 반환
   최종 View는 전달받은 Model 데이터를 바탕으로 화면을 렌더링하고, 그 결과를 클라이언트에게 응답으로 반환

HandlerMapping

• 클라이언트로부터 들어온 HTTP 요청의 URL, HTTP 메서드(GET, POST 등), 헤더 등을 기반으로 해당하는 Hander(controller)를 찾는 역할
• RequestMappingHandlerMapping : 애노테이션 기반(@RequestMapping) 컨트롤러를 처리
• BeanNameUrlHandlerMapping : 스프링 빈 이름과 URL을 매핑
• SimpleUrlHandlerMapping : XML 또는 Java 설정 파일에 명시적으로 정의된 URL 패턴과 핸들러를 매핑

HandlerAdapter

• 실제로 Handler를 실행할 Adapter를 찾아서 Controller 로직을 호출하는 역할
• RequestMappingHandlerAdapter : 애노테이션 기반 컨트롤러(@RequestMapping)를 처리
• HttpRequestHandlerAdapter : HttpRequestHandler 인터페이스를 구현한 핸들러를 처리
• SimpleControllerHandlerAdapter : 거 스타일의 컨트롤러(Controller 인터페이스 구현)를 처리
• SimpleServletHandlerAdapter: 표준 서블릿 인터페이스(javax.servlet.Servlet)를 구현한 클래스를 컨트롤러로 사용할 때 사용

ViewResolver

• 실행할 View를 찾는 역할
• Controller의 반환 값은 View의 이름, ViewResolver가 서버내의 적절한 뷰 파일 찾아 처리
• @RestController는 반환 값을 HTTP 응답 본문(Response Body)에 직접 작성하며, 반환 값은 일반적으로 JSON 형식으로 처리. Spring MVC는 이를 자동으로 처리하기 위해 HttpMessageConverter를 사용

DAO, VO,BO, DTO

• DAO(Data Access Object) : DB 데이터에 접근을 위한 객체(Repository, Mapper)
• VO(Value Object) : 실제 데이터만을 저장하는 객체
• BO(Business Object) : 여러 DAO를 활용해 비즈니스 로직을 처리하는 객체(Service)
• DTO(Data Transfer Object) : 각 계층간의 데이터 교환을 위한 객체

VO vs DTO
VO는 변하지 않는 객체, 오직 read만 가능
DTO는 읽고 쓰는 것 가능(가변성)

엔티티(Entity)
엔티티(Entity)는 데이터베이스 테이블과 1:1로 매핑되며, 고유 식별자를 가진 변경 가능한 객체로, 주로 CRUD 작업에 사용

DTO 사용 이유

• 순환 참조 예방
• 엔티티 내부 구현 캡슐화
• 역할 분리

Spring MVC

각 레이어간 기능을 구분하기 위한 디자인 패턴

Model, View, Controller

• Model : 데이터 관리 및 비즈니스 로직 처리(DTO, DAO, Service)
• View: 비즈니스 로직 처리결과를 유저(클라이언트에게) 보여주는 역할(html, jsp, thymeleaf)
• Controller : 사용자의 요청을 처리하고 Model , View 중개하는 역할(Model, View 연결 다리)

즉시 로딩(EAGER) vs 지연 로딩(LAZY)

• 즉시 로딩(EAGER): 조회시, 연관된 엔티티도 함께 조회

• 지연 로딩(LAZY): 연관된 엔티티가 실제 사용 될 때 조회

N+1 문제

• 보통 ORM을 사용할 때, 연관된 엔티티를 조회하는 문제로 예를 들어, 게시글 목록을 조회할 때, 각 게시글의 작성자 정보를 개별적으로 조회하는 경우, 이런 문제가 발생

• EAGER 방법 사용 -> JPA를 예를 들면 Join Fetch를 사용해서 연관 엔티티를 한번의 쿼리로 함께 조회하는 방법

• 배치 사이즈 설정 -> EAGER가 부담스러우면 배치사이즈를 설정해서 조회는 방식

• 연관관계에서 발생하는 이슈, 하나의 쿼리를 날렸을 때, N 만큼 연관된 쿼리 추가 실행

• 간단한 해결방법은 Fetch Join , @EntityGraph 사용

스프링 필터 (Spring Filter) vs 스프링 인터셉터(Spring intercepter)

호출되는 시점에 따라 둘을 구분 할 수있다. 스프링 필터 (Spring Filter)는 디스패처 서블릿(DispatcherServlet)으로 요청이 가기전에 실행되지만

스프링 인터셉터(Spring intercepter)는 Controller로 요청이 가기전에 실행된다.

@Requestbody,@RequestParam,@ModealAttribute

• @Requestbody : 클라이언트가 전송하는 JSON 형태의 HTTP Body 내용을 MessageConveter를 통해 자바 객체로 변환시켜주는 역할, Getter , Setter 없이도 정상적으로 할당

• @RequestParam :1개의 HTTP 요청 파라미터 받기위해 사용, 디폴트값 true(필수)

• @ModealAttribute: 클라이언트가 전송하는 폼(form) 형태의 HTTP Body와 요청 파라미터들을 생성자나 Setter로 바인딩하기 위해 사용

JPA

• 자바에서 RDB를 운용하기 위한 표준 자바 API
• 자바 객체와 DB 테이블 간의 연동을 용이하게 해주는 ORM 기능 제공
• SQL 작성 없이도 객체 지향적으로 DB 조작 가능

JPA 구현체
Hibernate, EclipseLink

영속성 컨텍스트

• 엔티티를 영구 저장하는 환경
• 엔티티 생명 주기 / 상태 관리
• JPA의 캐싱 , 쓰기 지연, 변경 감지 기능 제공

트랜잭션 관리

@Transactional 어노테이션 및 EntityManager를 통해 직접 트랜잭션 시작, 커밋 , 롤백 가능

ORM

• 객체 관계 매핑 의미, 객체지향언어에서 객체와 RDB의 테이블을 자동으로 매핑해주는 기술 , 다양한 DB와 호환

참고

• 김영한 스프링 핵심원리 기본편
• [Spring] 📚 Dispatcher Servlet 이해하기