항상 MVC 패턴에 대해 들어봤는데 제대로 알아본 적이 없던 것 같아서 이번 기회에 제대로 알아보려도 이 글을 작성하게 되었다.
MVC 이전 시대
우선 MVC 패턴이 나오게 된 배경에 대해 이해하는 게 좋을 것 같다. MVC 패턴 이전에 어떤 것이 있었고 어떤 문제가 있어서 MVC 패턴이 나오게 되었는지 알아보자.
JSP 모델 1
- 하나의 JSP 나 서블릿이 비즈니스 로직과 뷰 로직을 다루었다.
- 처음에는 한 곳에 작성해서 편하지만 유지보수 관점에서 매우 안 좋았다.
비즈니스 로직을 수정해야 할 때 JSP 파일을 열어보면 수정하지도 않을 HTML 코드들도 같이 보이게 되고 디버깅할 때 어디에 문제가 발생했는지 찾는 게 상당한 시간이 걸리게 된다.
하나의 JSP 파일이 너무나 많은 책임을 가지고 있게 되는 것이다. 프로젝트가 커지게 되면 하나의 JSP 파일에 얼마나 많은 JAVA 코드와 HTML 코드가 들어갈지 상상해 보자..
JSP 가 뭘까?
JSP는 JavaServer Page의 약자로 HTML 코드에 자바 코드를 넣어 동적인 페이지를 생성하는 웹 애플리케이션 도구이다.
<%@ page import="hello.servlet.domain.member.Member" %>
<%@ page import="hello.servlet.domain.member.MemberRepository" %>
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%
MemberRepository memberRepository = MemberRepository.getInstance();
System.out.println("MemberSaveServlet.service");
String username = request.getParameter("username");
int age = Integer.parseInt(request.getParameter("age"));
Member member = new Member(username, age);
memberRepository.save(member);
%>
<html>
<head>
<title>Title</title>
</head>
<body>
성공
<ul>
<li>id=<%=member.getId()%></li>
<li>username=<%=member.getUsername()%></li>
<li>age=<%=member.getAge()%></li>
</ul>
<a href="/index.html">메인</a>
</body>
</html>
위 코드가 JSP 코드인데 위쪽에는 자바로 비즈니스 로직이 있고 아래에는 HTML 페이지가 있는 것을 볼 수 있다.
JSP 모델 2
- MVC 패턴을 웹에 적용하기 시작
- 비즈니스(Model)와 출력(View)을 분리하기 시작
- 유지보수가 용이
비즈니스로직과 뷰 로직을 분리를 하여 책임을 분리하게 되면서 유지보수 관점에서 이전보다 많이 좋아졌다.
현재식 MVC 패턴 [ Apple에서 발표한 cocoa MVC 패턴 ]
- 현대식 MVC의 정의라고 봐도 무방하다.
- cocoa는 ios 설계에 사용되는 라이브러리라고 한다.
MVC 패턴 설명
MVC는 Model View Controller의 약자이다.
유지보수가 편해지는 코드 구성 방식
Model : 데이터와 관련된 책임을 담당
- 뷰에 출력할 데이터를 갖고 있다.
- 데이터만 가지고 있고 뷰와 컨트롤러를 몰라야 한다.
뷰와 컨트롤러를 몰라도 된다는 의미는 영향을 받지 않아야 한다는 의미이다. 모델 안에 뷰나 컨트롤러 관련 로직이 있으면 안 된다.
View : 사용자에게 보이는 인터페이즈 담당
- 웹 브라우저로 렌더링 되는 페이지가 해당된다.
- 모델에서 받은 데이터를 가지로 렌더링 하여 사용자에게 보이는 페이지
- 화면을 그리는 일에만 집중한다.
모델에서 받은 데이터를 저장해서는 안된다. 오직 그리는 일에만 집중해야 한다. 데이터를 저장하는 것은 모델에서 하는 것이다. 모델로부터 받은 데이터를 가지고 화면을 그리는 일에만 집중한다.
Controller : Model과 View를 연결 담당
- HTTP 요청을 받아서 파라미터를 검증하고, 비즈니스 로직을 실행한다.
- 뷰에 전달할 결과 데이터를 조회해서 모델에 담는다.
- 일종의 중계자
클라이언트의 요청을 받아서 비즈니스 로직을 실행하고 모델과 뷰를 호출한다.
컨트롤러도 어떻게 보면 중계자 책임과 비즈니스 로직 책임을 둘 다 감당하고 있다. 그래서 사실 비즈니스 로직은 Service라는 별도의 계층을 만들어서 처리한다.
장점
- 동시 다발적으로 개발할 수 있다.
- 프런트엔드와 백엔드가 독립적으로 개발할 수 있다.
- 높은 응집도를 가지게 된다.
- 뷰와 모델이 다른 레이어에서 독립된다.
- 유지보수에 좋다.
MVC 지키는 규칙
그러나 이론적인 것만 알고서 실제로 MVC 패턴을 구현하다가 보면 제대로 MVC 패턴을 지키면서 구현하는데 어려움을 겪게 된다. 그래서 다음과 같은 규칙을 지키면서 코드를 작성하다가 보면 MVC 패턴을 지키게 될 것이다.
- Model 은 Controller와 View에 의존해서는 안된다.
- View는 Model 에만 의존해야 하고, Controller에 의존하면 안 된다.
- View 가 Model로부터 데이터를 받을 때는, 사용자마다 다르게 보여줘야 하는 데이터만 받아야 한다.
- Controller는 Model과 View에 의존해도 된다.
- View 가 Model로부터 데이터를 받을 때 Contoller를 통해서 받아야 한다.
참고 페이지
'개발 스토리' 카테고리의 다른 글
| 컬렉션 프레임워크(Collection Framework) 은 뭐지?? (1) | 2023.10.23 |
|---|---|
| 자바 스트림(Stream)이란 무엇이고 왜 쓰는건가? (0) | 2023.10.22 |
| 레코드(record) 누구냐 넌? (2) | 2023.10.20 |
| Git 의 기본 동작과 Fork vs Clone (2) | 2023.10.20 |
| JAVA 8 버전으로 변경 (MAC M1, intelij) (0) | 2023.09.08 |
