반응형

정리(MVC 프레임워크 만들기)

지금까지 v1~v5로 점진적으로 프레임워크를 발전시켜 왔다.
지금까지 한 작업을 정리해보자.

  • v1: 프론트 컨트롤러를 도입
    • 기존 구조를 최대한 유지하면서 프론트 컨트롤러를 도입
  • v2: View 분류
    • 단순 반복 되는 뷰 로직 분리
  • v3: Model 추가
    • 서블릿 종속성 제거
    • 뷰 이름 중복 제거
  • v4: 단순하고 실용적인 컨트롤러
    • v3와 거의 비슷
    • 구현 입장에서 ModelView를 직접 생성해서 반환하지 않도록 편리한 인터페이스 제공
  • v5: 유연한 컨트롤러
    • 어댑터 도입
    • 어댑터를 추가해서 프레임워크를 유연하고 확장성 있게 설계

 

여기에 애노테이션을 사용해서 컨트롤러를 더 편리하게 발전시킬 수도 있다. 만약 애노테이션을 사용해서 컨트롤러를 편리하게 사용할 수 있게 하려면 어떻게 해야할까? 바로 애노테이션을 지원하는 어댑터를 추가하면 된다!
다형성과 어댑터 덕분에 기존 구조를 유지하면서, 프레임 워크의 기능을 확장할 수 있다.

 

스프링 MVC
여기서 더 발전시키면 좋겠지만, 스프링 MVC의 핵심 구조를 파악하는데 필요한 부분은 모두 만들어보았다.
사실은 여러분이 지금까지 작성한 코드는 스프링 MVC 프레임워크의 핵심 코드 축약 버전이고, 구조도 거의 같다.

스프링 MVC는 지금까지 우리가 학습한 내용과 거의 같은 구조를 가지고 있다.

 

v1~v5의 그림들을 살펴보며 마무리하자.

프론트 컨트롤러를 도입해서 우리만의 MVC 패턴을 만들었다.

 

그리고 프론트 컨트롤러를 도입했는데, v1에서는,
단순하게 도입했다.

v2에서는
반복되는 view때문에 view를 분리했다.
(참고로 JSP는 dispatcher로 foward를 해서 JSP를 랜더링해야하는데,
우리가 뒤에서 배울 thymeleafe는 진짜 view에서 랜더링 하게된다.)

 

v3에서는 여러가지를 바꿧는데,,
FrontController가 Controller를 호출하고, ModelView를 반환받았다.
그리고 논리적인 이름을 사용했다.
그리고 실제로 물리적인 이름과 MyView를 생성해서 반환해 주는 것은 viewResolver가 하도록 했다.
이렇게하면, 나중에 view에 대한 구체적인 것들이 변경되어도 viewResolver와 관련된 설정만 바꿔주면 된다.
참고로 스프링에서는 viewResolver도 전부 인터페이스로 되어있다.

 

ModelView를 반환해야하다보니, 개발하는 입장에서 너무 번거로웠다.
그래서 그냥 Controller에서는 ViewName을 반환하도록 하고,
model도 FrontController에서 반환하도록 넘겨줬다.

이때 강조한 것은,
"프레임워크나 공통 기능이 수고로워야 사용하는 개발자가 편리해진다."라는 것이다.

 

v5에서는 v3, v4등 기능을 다른 방식으로 확장하고 싶은 경우를 위해 어댑터개념을 도입했다.

그래서 매핑 정보에서 어댑터를 뒤져서 가지고 오고,
어댑터를 통해서 컨트롤러가 호출된다.
FrontController와 Controller가 서로 안맞지만, 중간에 어댑터가 다 맞춰주는 것이다.
넘어가는 것도 맞춰주고, modelView 반환하는 것 까지 전부 맞춰준다.

 

이렇게해서 v3, v4까지 사용가능하도록 확장했다.

반응형