◇ PART · MVC

MVC — 왜 분업하나

역할 분리가 만드는 유연성

학습 목표

  • MVC 패턴이 무엇인지 안다
  • 왜 한 덩어리 코드가 위험한지 안다
  • 분업이 만드는 유연성을 비유로 설명할 수 있다

⚠️ 분업 없는 코드

한 메서드에 다 박힌 코드

@RequestMapping("/board")
public String board() {
    // DB 연결, SQL 실행, 결과 가공, HTML 조립
    // ... 모두 여기서
}

화면 디자인 한 번 바꾸려고 SQL 코드도 손대야 한다면? 부서지기 쉽고, 테스트 불가능.

🛠️ MVC — Model · View · Controller

3 가지 역할로 분리
  • Model — 데이터·비즈니스 로직 (식재료, 레시피)
  • View — 화면 표시 (식탁, 메뉴판)
  • Controller — 요청 받기·응답하기 (종업원, 매니저)

비유 — 식당 인테리어 vs 셰프

분업 없는 식당 └─ 한 명이 주문 받고 / 요리하고 / 서빙 → 인테리어 바꾸면 주방도 영향 분업된 식당 (MVC) └─ 종업원(Controller) / 셰프(Service) / 식탁(View) 분리 → 인테리어(View) 바뀌어도 셰프(Service) 는 그대로

Spring 의 MVC 6 계층

실무에서는 MVC 를 더 잘게 쪼개 6 계층:

  • DispatcherServlet — 안내데스크 (모든 요청 진입점)
  • Controller — 종업원 (요청 받음)
  • Service — 메인 셰프 (비즈니스 로직)
  • DAO/Repository — 식재료 창고 관리자 (DB 접근)
  • DTO/VO — 그릇 (데이터 운반)
  • View — 식탁·메뉴판 (화면)

분업이 만드는 유연성

  • 화면 디자인 변경 → View 만 수정
  • 비즈니스 로직 변경 → Service 만 수정
  • DB 변경 → DAO 만 수정
  • 각 계층은 다른 계층의 코드를 모름

🔄 Before / After

Part 2 끝

Spring 프로젝트가 동작하지만 — 한 컨트롤러에 모든 게 들어 있다.

→
Part 3 시작

역할별로 분리된 6 계층의 큰 그림을 안다. 다음 차시들에서 각 계층의 역할을 깊이.

이번 차시의 데이터 흐름

Controller
→
Service
→
DAO
→
DB
● 분리된 계층들이 흐름에 줄지어 등장

정리

오늘 들고 가는 것

  • MVC = Model + View + Controller
  • 분업 → 한 계층 변경이 다른 계층에 영향 없음
  • 다음 차시 — 6 계층의 자세한 역할