Spring MVC & 3 Layer (by김동현튜터님)

Spring MVC (Spring Boot) 이게 뭐야?

---

Spring은 뭘까요?

Spring은 자바 어플리케이션 개발을 도와주는 프레임워크

Spring 생태계에는 여러가지 서비스가 있습니다!

채용 시장에서 종종 보이는 Spring 서비스

1. 스프링 MVC (Model-View-Controller)

• 목적: 전통적인 동기식 웹 애플리케이션 개발을 위한 프레임워크.
• 아키텍처: 동기식 요청-응답 기반으로 동작. 클라이언트가 요청을 보내면 서버는 요청을 처리하고, 처리 결과를 클라이언트에 응답으로 보냅니다.
• 주요 특징:
  • 전통적인 웹 개발에 많이 사용되며, 템플릿 엔진(e.g., Thymeleaf, JSP)과 함께 뷰(View)를 렌더링합니다.
  • HTTP 프로토콜을 기반으로 동작하며, RESTful 웹 서비스 구축에도 자주 사용됩니다.
  • 서블릿 API와 밀접하게 연동됩니다.

2. 스프링 Batch

• 목적: 대규모의 데이터 처리 작업을 배치로 실행하기 위한 프레임워크.
• 아키텍처: 대량의 데이터 처리(ETL 작업, 로그 처리, 대용량 데이터 변환 등)에 적합한 배치 처리 모델을 제공합니다.
• 주요 특징:
  • 트랜잭션 관리, 대량 데이터 처리, 재시도, 스킵 처리와 같은 배치 작업에 필수적인 기능들을 제공.
  • Job, Step, Reader, Processor, Writer 등의 핵심 개념을 바탕으로 배치 작업을 설계.
  • 주로 시간이 오래 걸리거나 시스템 리소스를 많이 사용하는 작업에 사용됩니다.
  • 스프링 MVC나 WebFlux와는 달리 실시간 요청-응답이 아닌 스케줄러 기반 또는 수동으로 실행되는 작업에 초점을 맞춥니다.

3. 스프링 WebFlux

• 목적: 비동기식, 논블로킹 웹 애플리케이션 개발을 위한 프레임워크.
• 아키텍처: 리액티브 스트림(reactive stream) 기반으로 동작하며, 비동기 논블로킹 방식으로 요청을 처리합니다.
• 주요 특징:
  • 리액터(Reactor) 라이브러리를 사용하여 데이터 스트림과 비동기 작업을 관리합니다.
  • 서버 자원의 효율성을 높이고 고성능 웹 애플리케이션을 구현하는 데 적합.
  • 이벤트 기반 아키텍처로 많은 동시 연결을 효율적으로 처리할 수 있습니다.
  • 전통적인 스프링 MVC와 달리 서블릿 API를 사용하지 않고, Netty 같은 논블로킹 서버를 사용할 수 있습니다.

각각의 차이 특장점은

• 스프링 MVC는 동기식 요청-응답 웹 애플리케이션을 위한 프레임워크이며, 전통적인 웹 애플리케이션 개발에 사용됩니다.
• 스프링 Batch는 대규모 데이터 처리 작업을 위한 배치 프레임워크로, 실시간이 아닌 일괄 작업에 적합합니다.
• 스프링 WebFlux는 비동기식 논블로킹 웹 애플리케이션을 위한 프레임워크로, 고성능, 고효율의 리액티브 애플리케이션을 개발하는 데 사용됩니다.

(참고자료)

웹 개발에 특화된 서비스

• Spring MVC 와 Spring Webflux서블릿 API는 자바 웹 애플리케이션에서 HTTP 요청과 응답을 처리하는 표준 인터페이스임. 스프링 MVC는 이 서블릿 API 위에서 동작하며, 동기식으로 요청을 처리함. 즉, 클라이언트가 요청을 보내면 서버는 그 요청을 처리하는 동안 스레드를 점유하고 대기함. 모든 처리가 완료된 후에 응답을 반환함.논블로킹 서버는 요청을 비동기적으로 처리함. Netty 같은 서버는 하나의 스레드가 여러 작업을 동시에 처리할 수 있도록 설계되었음. 스프링 WebFlux는 이러한 논블로킹 방식의 서버에서 동작할 수 있도록 설계된 프레임워크임. 서블릿 API 대신 리액티브 스트림 API를 사용하며, 비동기적이고 논블로킹 방식으로 요청을 처리함.
• 논블로킹 서버와 스프링 WebFlux
• 서블릿 API와 스프링 MVC

Spring MVC가 가장 전통적인 웹 개발에 사용됨. 가장 보편적으로 사용 된다는 것은 채용이 많다는 뜻이고 기본이라는 뜻임 그래서 우리가 Spring MVC를 배우고 있는 것임

MVC가 뭐이야!

MVC라는 것은 자바 문법 처럼 정해진 것 아니다.

추상적인 개념인것이고, 개발을 할 때 이런식으로 개념을 분리하고 파일을 분리해서 관리를 하면 보다 편하니 하나의 고정된 관례 약속이 되어버린 것임.

혹시 들어보셨는지는 모르겠지만 이런게 디자인 패턴이다.

MVC는 클라이언트와 서버간의 구조 관점에서 접근한 개념

1. Model (모델)

• 역할: 데이터와 비즈니스 로직을 다룹니다.
• 쉽게 설명: 모델은 애플리케이션이 관리해야 하는 정보나 데이터를 의미합니다. 예를 들어, 사용자의 정보(이름, 나이, 주소 등)를 저장하거나 데이터베이스에서 가져오는 작업을 담당합니다.
• 예시: 사용자가 스케줄 일정을 생성 하면 이를 생성하고 저장하는 역할을 수행하는 역할을 합니다.

2. View (뷰)

• 역할: 사용자가 보게 될 화면을 담당합니다.
• 쉽게 설명: 뷰는 데이터를 시각적으로 표현하는 부분입니다. 화면에 출력될 내용(HTML, 텍스트 등)을 만들고, 사용자에게 보여주는 역할을 합니다.
• 예시: 사용자가 스케줄 일정을 생성하는데 성공하면 "스케줄 생성 성공"이라는 메시지를 화면에 보여주는 것이 뷰의 역할입니다.

3. Controller (컨트롤러)

• 역할: 모델과 뷰를 연결하는 다리 역할을 합니다.
• 쉽게 설명: 컨트롤러는 사용자의 요청을 받아서, 그 요청을 처리하고, 결과를 뷰에 전달해 화면에 나타나게 하는 역할을 합니다.
• 예시: 사용자가 스케줄 일정을 요청을 하면, 컨트롤러는 그 요청을 받아 모델에게 전달해주고 모델에서 작업이 마무리되면 뷰에게 전달하는 역할을 합니다.

그런데 아직 MVC 패턴인가요? 왜 다른 건가요?

 옛날에 MVC 패턴이 생겨날 당시에는 스프링에서 데이터도 만들어주고 화면도  보여주는 방식이 일반적인 방식이였음

 그러나 점점 기술이 발전되면서 데이터를 만들어서 보여주는 서버와 사용자에게 화면을 보여주는 클라이언트 부분의 역할이 커지면서 복잡해지기 시작하여 이를 분리시켰음.

서버와 클라이언트 간의 데이터를 주고 받는   **RESTful API 가 주류로 자리 잡았음** 

이전에는 View를 통해서 직접 화면을 그려서 보여줬다면 요즘은 Json 형식으로 프론트에 데이터를 전달해주고 프론트에서 이를 받아서 사용자에게 보여줌

결론 : 방식이 변경 되었어도 개념은 동일하기 때문에 여전히 MVC 패턴임 

전체 흐름 ( 랜더링 버전 )

1. 사용자가 웹사이트에서 "Todo 스케줄 생성" 버튼을 클릭합니다 (요청).
2. 컨트롤러가 이 요청을 받아, 모델에게 Todo 스케줄을 생성하도록 지시합니다.
3. 모델이 데이터베이스에서 사용자의 정보를 확인하고, 결과를 컨트롤러에게 전달합니다.
4. 컨트롤러는 그 결과를 뷰에 전달하여 사용자가 보게 될 화면을 만듭니다.
5. 최종적으로 뷰는 "Todo 스케줄 생성 성공"이라는 화면을 사용자에게 보여줍니다 (응답).

전체 흐름 ( RESTful API 버전 )

1. Todo 스케쥴 작성을 위해서 Postman 을 통해서 일정 생성 api를 호출합니다.
2. 컨트롤러가 이 요청을 받아, 모델에게 Todo 스케줄을 생성하도록 지시합니다.
3. 모델이 스케줄을 생성하고 결과를 컨트롤러에게 전달합니다.
4. 컨트롤러는 그 결과를 뷰에 전달하여 Postman에 전달하기 위한 Json 형식을 만듭니다.
5. 최종적으로 뷰는 Json을 Postman에 전달합니다.

Spring 3 Layer 이건 또 뭐이야?

---

Spring 3 Layer 는 서버 개발 관점에서 각 계층 별로 역할을 분리하는 개념

1. Presentation Layer (프레젠테이션 레이어) Controller

• 역할: 사용자가 입력한 데이터의 형식이나 간단한 유효성 검사를 수행합니다. 예를 들어, 입력 필드가 빈 값인지, 숫자 필드에 숫자가 들어왔는지, 이메일 형식이 올바른지 등을 검증합니다.
• 쉬운 설명 :
  • 사용자가 입력한 요청이 유요한 요청인지 검사하고 필터링 하는 역할
  • 사용자에게 요청을 받고, 데이터를 전달하는 역할
• 구성 요소:
  • Controller: Spring MVC의 @Controller 또는 @RestController
• 예시
• public class UserDTO { @NotNull @Size(min = 2, max = 30) private String name; @NotNull @Email private String email; // getters and setters } @RestController @RequiredArgsConstructor public class UserController { private final UserService userService; @PostMapping("/user") public String createUser(@Valid @ModelAttribute("user") UserDTO userDTO, BindingResult result) { if (result.hasErrors()) { return "errorPage"; } userService.createUser(userDTO); return "successPage"; } }

2. Service Layer (서비스 레이어) Service

• 역할: 비즈니스 로직을 처리하는 핵심 레이어입니다. Presentation Layer와 Data Access Layer 사이에서 중간 역할을 합니다. Presentation Layer의 요청을 받아 필요한 데이터를 가공하거나 로직을 실행하여 결과를 반환합니다.
• 쉬운 설명 :
  • 사용자가 요청한 요구사항이 실질적으로 처리하는 역할
• 구성 요소:
  • Service: @Service 어노테이션으로 표시된 클래스
• 예시
• @Service @RequiredArgsConstructor public class UserService { private final UserRepository userRepository; public void createUser(UserDTO userDTO) { if (userRepository.existsByEmail(userDTO.getEmail())) { throw new IllegalArgumentException("Email already in use."); } // Further business logic User user = new User(userDTO.getName(), userDTO.getEmail()); userRepository.save(user); } }

3. Data Access Layer (데이터 접근 레이어) Repository

• 역할: 데이터베이스와 상호작용하며, 데이터를 저장, 검색, 업데이트, 삭제하는 역할을 합니다. 비즈니스 로직에서 데이터를 필요로 할 때 이 레이어를 통해 데이터를 처리합니다.
• 쉬운 설명 :
  • 스프링에서 데이터 베이스의 데이터를 처리하는 역할
• 구성 요소:
  • Repository : @Repository 어노테이션으로 표시된 클래스들이 여기에 속하며, JPA, Hibernate, MyBatis 등과 같은 ORM(Object-Relational Mapping) 프레임워크를 사용해 데이터베이스와 상호작용합니다.
  • Entity: 데이터베이스 테이블과 매핑되는 도메인 객체로, 데이터베이스에서 가져오거나 저장할 데이터를 캡슐화합니다.
• 예시
• @Repository @RequiredArgsConstructor public class UserService { private final JdbcTemplate jdbcTemplate; public Optional<User> existsByEmail(UserDTO userDTO) { List<Manager> result = jdbcTemplate.query("SELECT * FROM user WHERE id = ?", rowMapper(), userDTO.getUserId()); return result.stream().findFirst(); } }

Spring 3 Layer ? 오케이 그럼 이거 왜 쓰는거야?

### 1. **책임의 분리 (Separation of Concerns)**

- **설명:** 3-Layer 아키텍처는 Presentation, Service, Data Access의 세 가지 계층으로 애플리케이션을 나눔으로써, 각 계층이 특정 역할만을 수행하도록 만듭니다. 이로 인해 코드의 역할이 명확해지고, 각 계층이 자신의 책임에 집중할 수 있게 됩니다.
- **효과:** 각 계층이 독립적으로 변화할 수 있어, 한 계층의 변경이 다른 계층에 미치는 영향을 최소화할 수 있습니다. 예를 들어, 데이터베이스 구조가 변경되어도 Presentation Layer에는 영향을 미치지 않도록 할 수 있습니다.

### 2. **유지보수성 (Maintainability)**

- **설명:** 코드의 역할이 명확히 분리되어 있기 때문에, 특정 기능을 수정하거나 확장할 때, 관련된 계층만 수정하면 됩니다. 이로 인해 코드의 복잡성이 줄어들고, 유지보수가 쉬워집니다.
- **효과:** 예를 들어, 비즈니스 로직이 변경되면 Service Layer에서만 수정하면 되고, Presentation Layer나 Data Access Layer는 건드릴 필요가 없습니다. 이는 유지보수 시 버그 발생 가능성을 줄이고, 작업 시간을 단축시킵니다.

### 3. **재사용성 (Reusability)**

- **설명:** 3-Layer 아키텍처를 사용하면, 특정 계층의 코드가 다른 애플리케이션이나 모듈에서 재사용될 수 있습니다. 예를 들어, 동일한 비즈니스 로직이 여러 애플리케이션에서 사용된다면, Service Layer의 코드를 재사용할 수 있습니다.
- **효과:** 재사용성을 높임으로써 개발 속도를 향상시키고, 중복된 코드 작성에 따른 실수를 줄일 수 있습니다. 또한, 재사용 가능한 코드 모듈을 만들어 테스트와 유지보수를 용이하게 합니다.

### 4. **테스트 용이성 (Testability)**

- **설명:** 각 계층이 독립적이기 때문에, 개별 계층을 쉽게 테스트할 수 있습니다. Service Layer나 Data Access Layer를 각각 단위 테스트(Unit Test)하거나, Presentation Layer를 통합 테스트(Integration Test)로 테스트할 수 있습니다.
- **효과:** 단위 테스트를 통해 개별 모듈의 기능을 철저히 검증할 수 있으며, 계층별로 발생할 수 있는 버그를 조기에 발견하여 수정할 수 있습니다. 이는 시스템의 안정성과 품질을 높이는 데 기여합니다.

### 5. **확장성 (Scalability)**

- **설명:** 3-Layer 아키텍처는 애플리케이션이 확장될 때, 각 계층이 독립적으로 확장 가능하도록 도와줍니다. 예를 들어, 트래픽이 증가할 때, Presentation Layer와 Service Layer를 각각 독립적으로 확장하여 부하를 분산시킬 수 있습니다.
- **효과:** 계층별로 확장이 가능하기 때문에, 특정 기능이나 모듈만 성능 개선이 필요할 때에도 전체 시스템에 영향을 주지 않고 개선할 수 있습니다.

### 6. **보안성 (Security)**

- **설명:** 3-Layer 아키텍처는 Presentation Layer에서 사용자로부터 입력된 데이터를 Service Layer로 전달하기 전에 유효성을 검사할 수 있으며, Service Layer에서 비즈니스 로직을 통해 다시 한 번 검증하여 안전한 데이터만 Data Access Layer로 전달할 수 있습니다.
- **효과:** 보안적인 측면에서 계층별로 데이터를 검증하고 관리할 수 있어, 악의적인 입력이나 잘못된 데이터가 시스템 깊숙이 침투하는 것을 방지할 수 있습니다.

DTO가 뭘까요 ? 기억 나시나요?

• data transfer object
• 계층간의 데이터 이동
• 지식의 파편들이 연결되는 것이 느껴지시나요?

Spring MVC, Spring 3 Layer 살려주세요…

Spring MVC, Spring 3 Layer는 비슷해 보이지만 서로 다른 개념입니다.

MVC는 클라이언트와 서버간의 구조 관점에서 접근한 개념

Spring 3 Layer 는 서버 개발 관점에서 각 계층 별로 역할을 분리하는 개념

Spring MVC

주된 관심사 :

• 사용자 요청 처리와 응답 생성
  • Spring MVC의 주요 목적은 클라이언트(사용자)와 서버 간의 상호작용을 관리하는 것입니다. 이를 통해 웹 애플리케이션이 사용자의 요청을 받아 처리하고, 그 결과를 사용자에게 적절한 형식으로 반환하는 과정을 쉽게 구현할 수 있습니다

Spring 3 Layer

주된 관심사:

• 애플리케이션의 구조화 및 계층화

Spring 3 Layer 는 애플리케이션을 세 개의 주요 계층으로 나누어 각 계층이 독립적으로 동작할 수 있도록 구조화하는 데 초점을 맞추고 있습니다. 이를 통해 애플리케이션의 유지보수성과 확장성을 향상시킬 수 있습니다.