TIL

10월 30일 수요일
AM 알고리즘 문제 풀이, 강의 수강
PM 2,3,4주차 강의 수강

💡 Today Issue

MVC 패턴

🤔 나의 생각 + 배운 것

MVC(Model View Controller) 패턴

• Controller :
  HTTP Request를 전달받아 파라미터를 검증한다.
  비지니스 로직을 실행한다.
  View에 전달할 결과를 조회하여 Model 객체에 임시로 저장한다.

• Model :
  View에 출력할 Data를 저장하는 객체이다.
  View는 비지니스 로직이나 Data 접근을 몰라도 되고 View Rendering에만 집중하면 된다.

• View :
  Model 객체에 담겨져 있는 Data를 사용하여 화면을 Rendering 한다.

---

MVC 패턴의 문제점

• View로 이동하는 forward가 항상 중복 호출된다.
• View의 path를 입력한다.(중복 작업)
• HttpServiceResponse 객체를 사용하는 경우가 적다. (JSP에서 모두 해결하기 때문)
  ➔ HttpServletRequest와 HttpServletResponse는 Test 코드를 작성하기도 매우 힘들다.
• 공통 기능이 추가될 때 Controller에서 처리해야 하는 부분들이 많아진다.
  ➔ 공통 기능 처리 : 모든 컨트롤러에서 공통으로 적용되는 기능을 뜻한다.

---

프론트 컨트롤러 패턴

프론트 컨트롤러의 역할

• 모든 요청을 하나의 프론트 컨트롤러가 받는다.
• 공통 기능을 처리한다.
• 요청을 처리할 수 있는 Controller를 찾아서 호출한다.(Controller Mapping)
• 프론트 컨트롤러를 제외한 나머지 컨트롤러는 Servlet을 사용하지 않아도 된다.
  ➔ 일반 Controller들은 HttpServlet을 상속받거나, @WebServlet을 사용하지 않아도 된다.

프론트 컨트롤러 패턴의 문제점

• 공통 처리 로직에 연결하기 위해 Controller에서 return 하는 결과가 동일해야 한다.
• 하지만 Controller에서 응답해야하는 결과는 각자 다르고, 응답을 동일하게 맞추려하면 애플리케이션은 확장성, 유지보수성을 잃게된다.
• 공통 로직에서 응답별로 퍼즐을 하나하나 처리하게 되면 공통 부분의 책임이 너무 커지게 된다.

어댑터 패턴

• 컨트롤러(Handler)는 비지니스 로직을 처리하고 알맞은 결과를 반환한다.
• 어댑터는 공통 로직과 컨트롤러(Handler)가 자연스럽게 연결되도록 한다.
• 프론트 컨트롤러는 공통으로 처리되는 로직을 수행한다.

장점

• 프론트 컨트롤러, 어댑터, 핸들러 모두 각자의 역할만 수행한다. (책임 분리)
• 새로운 컨트롤러(Handler)가 추가되어도 컨트롤러와 어댑터만 추가한다면 공통 로직의 변경이 발생하지 않는다.

🕐회고

새로운것을 배우니 꽤나 재미있다. 이제 시작이니 해이해지지 않도록 노력하자.