밤빵's 개발일지
[TIL]20240709 DispatcherServlet..? 본문
MVC패턴에 대해서 공부하는데 밑에 계속 혼란스러운 그림이있고, DispatcherServlet 이라는 낯선 이름까지..
쓸데없이 하나 꽂히면 파고들어서 공부할 시간 잡아먹는 성격이라 애써 흐린눈 했는데 이걸 모르면 안되는거 같아서,
꼭 따로 정리해둬야지 해서 하나씩 정리하기 시작!
강의자료에 있는 그림부터 하나하나 이해해보기로 했다.
▶ DispatcherServlet 작동 과정
1. 요청(Request)
→ 사용자의 요청이 들어오면, 이 요청은 가장 먼저 DispatcherServlet에 도달한다.
DispatcherServlet은 모든 요청을 중앙에서 처리하는 스프링 MVC의 프론트 컨트롤러 역할을 한다.
2. Handler Mapping 검색
→ DispatcherServlet은 요청 URL에 따라 어떤 컨트롤러(Controller)가 요청을 처리할지 결정하기 위해 Handler Mapping을 조회한다. Handler Mapping은 URL과 해당 요청을 처리하는 컨트롤러의 메서드 사이를 연결해주는 역할을 한다.
3. Controller 호출
→ Handler Mapping을 통해 결정된 컨트롤러가 호출된다. Controller는 요청을 처리하고 비즈니스 로직을 수행한다. 필요한 데이터를 가져오기 위해 서비스 계층과 상호작용 할 수 있다.
4. Model 과 View 이름 반환
→ Controller 는 처리 결과를 Model객체와 함께 논리적 뷰 이름 (logical view name) 을 DispatcherServlet에 반환한다. 이 Model객체는 클라이언트에게 응답할 때 사용할 데이터.
▷ 논리적 뷰 이름..?
@Controller
public class PaymentController {
// URL 매핑: /payment
@PostMapping("/payment")
public String processPayment() {
// 결제 로직 처리 후 "paymentSuccess"라는 논리적 뷰 이름 반환
return "paymentSuccess";
}
}
→ paymentSuccess 가 논리적 뷰 이름. 왜 이렇게 어렵게 설명해놓은거야😟
5. View Resolver를 사용하여 View 결정
→ DispatcherServlet은 View Resolver를 사용하여 논리적 뷰 이름을 실제 뷰(View)로 변환한다. View Resolver는 설정에 따라 어떤 템플릿 파일(JSP, Thymeleaf 등)을 사용할지 결정한다.
▷ View Resolver
→ 논리적 뷰 이름을 실제 뷰 파일의 경로로 변환하는 역할 . Spring MVC에서 뷰 리졸버는 클라이언트에게 반환할 최종 HTML 페이지를 결정하는 중요한 구성 요소이다.
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.ViewResolver;
import org.springframework.web.servlet.view.InternalResourceViewResolver;
@Configuration
public class WebConfig {
@Bean
public ViewResolver viewResolver() {
InternalResourceViewResolver resolver = new InternalResourceViewResolver();
resolver.setPrefix("/WEB-INF/views/"); // 뷰 파일의 경로 앞부분 설정
resolver.setSuffix(".jsp"); // 뷰 파일의 확장자 설정
return resolver;
}
}
→ GPT한테 예시를 들어달라고 했더니 처음보는 클래스 이름이 나왔다 config,,,? 이 예시는 도저히 이해할 수 가 없다 ㅠㅠㅠ 나중에 시간이 지나면 이해할 수 있으려나.....
6. View 렌더링
→ 결정된 View는 모델 데이터를 사용해 HTML, JSP, 또는 다른 형태의 응답으로 렌더링 된다. 이 뷰는 클라이언트가 볼 수 있는 최종 응답 페이지를 생성한다.
▷ 렌더링 (Rendering)
→ 웹 개발에서 사용자에게 보여줄 최종 화면을 만드는 과정. 이 과정에서 코드는 화면에 표시되는 컨텐츠( 텍스트, 이미지, 버튼 등)로 변환된다. 쉽게 말해서 렌더링은 코드를 실제 눈에보이는 화면으로 만드는 것 이라고 생각할 수 있다.
- 서버 측 렌더링 (SSR) : 서버가 HTML을 생성하여 브라우저로 전송한다.
- 클라이언트 측 렌더링(CSR) : 브라우저가 JavaScript로 HTML을 동적으로 생성한다.
😵💫 서버는 뭐고 클라이언트는 뭘까..... 아직 갈 길이 너무너무나 멀다 ㅠㅠㅠㅠㅠㅠ
7. 응답(Response) 반환
→ 최종적으로 렌더링 된 뷰는 DispatcherServlet을 통해 사용자에게 응답(Response)으로 반환된다.
▶ 정리
→ 스프링 MVC에서 요청을 처리하는 과정은 중앙 집중형 구조로, DispatcherServlet이 모든 요청을 관리하고 각 단계의 컴포넌트(Handler Mapping, Controller, View Resolver 등)를 통해 요청을 처리하여 최종 응답을 생성한다. 이러한 구조 덕분에 애플리케이션의 확장성과 유지보수성이 높아진다.
▷ 컴포넌트
→ 시스템을 구성하는 독립적이고 재사용 가능한 모듈을 의미한다. 특정 기능을 수행하는 코드 블록이나, 서비스, 라이브러리 등을 가리킨다.
▷ 컴포넌트 개념
1. 재사용성(Reusability)
→ 컴포넌트는 독립적으로 설계되어 여러 프로젝트나 모듈에서 재사용할 수 있다. 인증 컴포넌트를 예로 들면 여러 애플리케이션에서 공통으로 사용할 수 있다.
2. 독립성(Independence)
→ 컴포넌트는 서로 다른 컴포넌트에 영향을 받지 않고 독립적으로 동작할 수 있다. 유지보수와 확장이 용이하다.
3. 캡슐화(Encapsulation)
→ 각 컴포넌트는 내부 구현을 숨기고, 명확한 인터페이스(API)를 통해 다른 컴포넌트와 상호작용한다. 이로 인해 변경이 발생해도 다른 컴포넌트에 미치는 영향을 최소화 할 수 있다.
▷ 백엔드에서는 모듈, 서비스 . 패키지 등이 컴포넌트의 예가 될수있다.
→ 예시 : Spring Boot 서비스 컴포넌트
@Service
public class UserService {
private final UserRepository userRepository;
// 생성자 주입
public UserService(UserRepository userRepository) {
this.userRepository = userRepository;
}
public User findUserById(Long id) {
// 사용자 조회 로직
return userRepository.findById(id).orElseThrow(() -> new UserNotFoundException(id));
}
public User saveUser(User user) {
// 사용자 저장 로직
return userRepository.save(user);
}
}
→ Spring Boot에서 서비스 레이어는 독립적인 비즈니스 로직을 처리하는 컴포넌트이다. 예시의 UserService 컴포넌트는 레포지토리를 사용하여 사용자를 데이터베이스에서 조회하거나 저장하는 로직을 캡슐화 하고있다.
→ 컴포넌트는 재사용 가능하고 독립적으로 동작하며, 명확한 인터페이스를 통해 상호작용하는 모듈이나 서비스이다.
→ Java Spring Boot에서는 서비스 클래스, 레포지토리, 컨트롤러 등이 컴포넌트가 될 수 있다.
→ 컴포넌트를 잘 설계하면 유지보수성과 확장성이 높은 애플리케이션을 만들 수 있다.
😵💫오늘의 소감
내용을 정리하는데 모르는 단어들이 한 무더기다. 개발일지는 잠시 과제와 강의를 내려놓고 알아보려고 했던 정보를 정리하며 쓰는중인데.. 오늘 내용을 정리하면서 모르는 단어들 알아보느라 개발일지를 쓰는 시간이 점점 늘어가고있다. 시간이 지나면 이런 내용들이 익숙해져서 뭐가뭔지 알 날이 오긴하는지 싶다ㅠ 이름들도 왜 하나같이 어려운지.. 오늘 렌더링. 컴포넌트 다 하나같이 낯선 단어들 뿐이라 어색하고 걱정만 한가득.....
'개발Article' 카테고리의 다른 글
[TIL]20240711 Dto 사용의 중요성 (0) | 2024.07.12 |
---|---|
[TIL]20240710 Controller를 이해해보자! (0) | 2024.07.12 |
[TIL]20240708 MVC패턴 (0) | 2024.07.09 |
[WIL]20240707 Spring은 너무 팍팍해... (0) | 2024.07.07 |
[TIL]20240706 드디어 람다를 이해할 수 있나..?! (0) | 2024.07.07 |