ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • [Spring] MVC 패턴 문제
    Spring 2025. 3. 29. 22:08

     MVC 패턴 과정 중  Model 데이터 산출과 View 화면담당의 일이 독립적으로 작업을 하지만 Controller에게는 아직 까지 해결해야는 문제가 많다. 

     

    MVC 패턴 사용의 문제점은  블로그를 제작 한 다음, 블로그를 생성하는 Controller, 저장하는Controller, 조회하는 Controller들의 모든 컨트롤러에서 공통으로 적용되는 기능( log 출력, 인증, 인가 등등)포함되어 있으면, 반복적으로 호출해야하는 경우가 생긴다. 

    MVC 패턴 => 공통 기능 처리 패턴

    MVC 패턴 공통 기능 처리 패턴
    공통 기능이 추가될수록   Controller에서 처리해야 하는 부분들이 많아진다 Method 또한 항상 중복적으로 호출이 필요

    개발자가 작업하다보면 Method를 호출하는 일을 깜빡 할수도 있다.

    Method가 많아지면 많아질수록 Controller의 책임이 점점 커진다.

     

    입구가 오직 하나!

    프론트 컨트롤러(Servlet)에서 공통 기능을 처리하면 된다.

    프론트 컨트롤러 패턴 구조

     

     

     

      역활과 장점 모든 요청을 하나의 프론트 컨트롤러가 받는다.
    공통 기능을 처리한다.
    요청을 처리할 수 있는 Controller를 찾아서 호출한다.(Controller Mapping)
    프론트 컨트롤러를 제외한 나머지 컨트롤러는 Servlet을 사용하지 않아도 된다.
       
    문제점 프론트 컨트롤러에 연결 되기 위해 모든 컨트롤러의 return 결과의 형태가 동일해야한다.
    로직이나 응답해야하는 결과는 당연히 다를테고 응답을 동일하게 맞추려고 한다면 해당 애플리케이션은 확장성, 유지보수성을 잃는다.
    공통 로직에서 응답별로 퍼즐을 다시 하나하나 처리할 수 있으나 공통 부분의 책임이 너무 커지게된다.
    컨트롤러에서 반환되는 결과가 달라지면 공통처리 부분의 변경또한 불가피하다.

     

    공통 처리과정을 하나의 프론트 컨트롤러가 대신해주면 좋지만, 모든 컨트롤러의 return 결과의 형태가 동일해야 한다던지, 확장성, 유지보수성의 고려,  공통 부분의 책임이 너무 커지고, 과가 달라지면 공통처리 부분의 변경또한 불가피하는 큰 문제점이 있다.

     

     

    형태가 달라고, 모두다 연결 될 수 있다면?

          어뎁터가 다르면 중간에 입력 단자가 같은 어뎁터로 연결하면 되지 않을까? 

     

    어뎁터 패턴!

     

    다양한 컨트롤러(Handler)를 유연하게 만들기위해 어댑터 패턴을 도입하게 되었다.

     

    컨트롤러들은 동일한 인터페이스를 구현하도록 하고 해당 인터페이스와 공통 로직 사이에 어댑터를 두어 유연하게 만든다.

    서로 다른 인터페이스를 갖는 두 클래스를 연결해주는 패턴이다

    1. 컨트롤러(Handler)는 비지니스 로직을 처리하고 알맞은 결과를 반환한다.
    2. 어댑터는 공통 로직과 컨트롤러(Handler)가 자연스럽게 연결되도록 한다.
    3. 프론트 컨트롤러는 공통으로 처리되는 로직을 수행한다.
    • 어댑터 패턴 장점
      • 프론트 컨트롤러, 어댑터, 핸들러 모두 각자의 역할만 수행한다. (책임 분리)
      • 새로운 컨트롤러(Handler)가 추가되어도 컨트롤러와 어댑터만 추가한다면 공통 로직의 변경이 발생하지 않는다.

    'Spring' 카테고리의 다른 글

    [Spring] 과제 - Trobleshooting Session을 이용한 로그인 유지.  (1) 2025.04.04
    [Spring] SpringMVC  (0) 2025.03.30
    [Spring] MVC 패턴  (0) 2025.03.29
    [Spring] Annotation  (0) 2025.03.29
    [Spring] HTTP Method 속성  (0) 2025.03.27
Designed by Tistory.