Servlet으로 비지니스 로직과 View Rendering까지 모두 처리하면 너무 많은 역할을 하게 되고 유지보수가 굉장히 어려워져서 Spring MVC 패턴이 나오게 되었다.
그럼 Servlet이 비니지스 로직, 뷰까지 처리하는 코드를 보자.
@WebServlet("/products")
public class ProductServlet extends HttpServlet {
@Override
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
// 1. 비즈니스 로직 (상품 목록 생성)
List<String> products = new ArrayList<>();
products.add("Laptop");
products.add("Smartphone");
products.add("Tablet");
// 2. 뷰 렌더링 (HTML 생성 및 출력)
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("<!DOCTYPE html>");
out.println("<html>");
out.println("<head><title>Product List</title></head>");
out.println("<body>");
out.println("<h1>Product List</h1>");
out.println("<ul>");
for (String product : products) {
out.println("<li>" + product + "</li>");
}
out.println("</ul>");
out.println("</body>");
out.println("</html>");
}
}위 코드를 보면 Servlet으로 모든 역할을 처리할 때 나타나는 문제점을 확인해보자!
- 역할 분리 부족
- 비지니스 로직과 뷰 렌더링이 같은 코드에 섞여있음.
- 코드를 수정하거나 기능을 추가하려면 많은 부분을 변경해야 함.
- 유지 보수 어려움
- HTML 변경이 필요하면 Servlet 파일을 수정해야함.
- 협엽을 하면 충돌 발생 가능성 많음. (예를 들어 뷰를 처리하는 개발자와 서비스 로직을 처리하는 개발자가 서로의 코드를 건드림)
- 재사용성 낮음
- 비지니스 로직과 뷰가 강하게 결합되어 있어, 다른 곳에서 동일한 로직을 사용할 수 없다.
이러한 문제를 해결하기 위해 MVC 패턴이 등장하게 됨.
- Controller
- HTTP Request를 전달받아 파라미터를 검증한다.
- 비지니스 로직을 실행한다.
- 비지니스 로직을 Controller에 포함하게 되면 Controller가 너무 많은 역할을 담당하게 되어 일반적으로 Service Layer를 별도로 만들어서 처리
- Database와 상호작용 하는 Layer를 따로 구분하여 Repository Layer를 추가로 구성한다.
- Controller는 일반적으로 Service Layer를 호출하는 역할을 담당한다.
- View에 전달할 결과를 조회하여 Model 객체에 임시로 저장한다.
- Model
- View에 출력할 Data를 저장하는 객체이다.
- View는 비지니스 로직이나 Data 접근을 몰라도 되고 View Rendering에만 집중하면 된다.
- View
- Model 객체에 담겨져 있는 Data를 사용하여 화면을 Rendering 한다.
'Back-End > Spring-MVC' 카테고리의 다른 글
| HTTP 응답 데이터 (1) | 2024.12.02 |
|---|---|
| HTTP 요청 데이터 (1) | 2024.12.02 |
| @RequestMapping (0) | 2024.12.01 |
| @Controller 와 @RestController 요약 정리 (0) | 2024.12.01 |
| Spring MVC 구조 흐름 (0) | 2024.11.30 |
