MVC패턴이란
## 디자인패턴! MVC패턴은 디자인 패턴의 한 종류입니다. 일단 디자인 패턴이 더 큰 범주이니 디자인 패턴에 대해서 설명하자면 자바나 c#같은 객체 지향 프로그래밍 설계를 할 때 자주 발생하는 문제들을 피하기 위해 사용되는 패턴으로 정의됩니다. 쉽게말해서 여러명이 협업해서 개발하는 경우 A사람의 코드를 B사람이 이해하기는 어렵습니다. 이렇게 이해하기 힘든 코드를 해석하고 수정하는일은 시간이 더 많이 소요되고 번거롭죠.. 이제 이런 문제점들을 디자인 패턴이라는 일종의 의사소통 수단으로 해결을 하기로 한 것 입니다. 이러한 패턴들은 문제가 발생했을때 해결의 방법을 제안하는데 있어서도 복잡하게 말할거 없이 Facade 패턴으로가보자 뭐 이런식으로 말을 할 수 있게 되는 것이죠. 이야기만 들어보면 패턴은 무적인거 같고 그 방법으로는 무슨 문제든 해결할 거라고 생각할 수 있지만 이것도 너무 과해져서 모든 문제를 패턴을 사용하려고 한다면 '코드베이스의 간결성'을 잃기 때문에 적당하게 판단하는게 중요한 것 같습니다(극한의 효율충). 정말 많은 종류가 있지만 오늘은 JSP를 공부하면서 계속 등장하고 있는 MVC패턴 (Model, view, Controller)에 대하여 공부를 해봅니다. ## MVC pattern 일단은 이 패턴(모델-뷰-컨트롤러)은 사용자 인터페이스, 데이터 및 논리제어를 구현하는데 널리 사용되는 소프트웨어 디자인 패턴입니다. 소프트웨어의 비즈니스 로직과 화면을 구분하죠. 이러한 구분은 업무를 할때 더 나은 분리와 관리를 용이하게 해줍니다. 부분별로 설명드리자면, 모델은 데이터, 비지니스로직관리, 뷰는 레이아웃과 디스플레이 처리, 컨트롤러는 명령을 받아서 뷰와 모델로 라우팅하는 역할을 합니다.
MVC 패턴 5계층
자바를 통해 기업용 비지니스 시스템을 구축하는 것에 어려움을 느낀 개발자들이 복잡도를 낮추기위해 MVC패턴이 녹아있는 n-계층 C/S 환경을 구성하였고 이러한 계층이 시간이 지나면서 일반화 되어 5가지 계층으로 나뉘어서 적용되고 있습니다.
계층에 대한 설명은 http://egloos.zum.com/mt1716/v/9291203에서 퍼왔습니다.
5계층을 식당처럼 표현한게 이해가 잘가는 것 같습니다.
출처: https://postitforhooney.tistory.com/entry/Spring-MVC-패턴에서의-5가지-계층에-대한-정보-퍼옴 [PostIT]
1. 프리젠테이션 계층
◆ 역할 : 프리젠테이션 계층은 말 그대로 사용자 인터페이스에 불과하다. 식당을 예로 들면 손님이 접하게 되는 메뉴판과 전달될 음식을 차려놓는 식탁에 해당한다.
◆ 기능 : 사용자가 선택할 수 있는 기능이 표시되어 있어야 하고, 요청에 필요한 부가적인 정보 전달을 위한 입력 양식이 있어야 한다. 또한 전달된 자료를 효과적으로 보여주기 위한 프리젠테이션 로직이 포함된다. 하지만 비즈니스 로직이나 퍼시스턴스 계층에서 처리하는 일을 직접 수행하거나(스크립트 릿 사용), 각 계층의 컴포넌트와 직접적인 통신이 있어선 안된다.
모든 요청은 제어 계층을 통해 처리되어야 한다는 뜻이다. 고급 레스토랑(엔터프라이즈 시스템)에서는 웨이터(지배인)를 통해서만 요구를 전달하고, 그 결과를 전해들어야 한다. 직접 주방장에게 주문을 하거나 자기가 직접 요리를 하는 것은 자기 집(프로토타입)이나 동네 자장면 가게(소규모 웹 애플리케이션)에서나 가능한 일이다.
◆ 대안 기술 : 현재 가장 주류를 이루는 기술은 JSP 1.2와 JSTL과 같은 태그 라이브러리를 결합하는 방식이다. 과도기적인 형태로 벨로시티와 타일즈 태그 라이브러리가 결합된 형태도 현재 주목을 받고 있다. 하지만 점차적으로 JSF에 기반한 JSP 2.0에 주류 기술로 옮겨갈 가능성이 크고, 프리젠테이션 계층 개발에 있어서도 JSF를 지원하는 IDE를 채택하는 경우가 늘어날 것이다.
◆ 주요 패턴 : Composite View 패턴
- 제어 계층
◆ 역할 : 제어 계층은 프리젠테이션 계층과 비즈니스 로직 계층을 분리하기 위한 컨트롤러를 제공한다. 식당으로 치자면 지배인의 역할과 종업원의 역할을 병행하는 것이라고 볼 수 있다.
◆ 기능 : 전체 시스템의 설정 상태를 유지해야 하며, 그를 통해 어떤 요청이 들어왔을 때 어떤 로직이 처리해야 하는지를 결정한다. 사용자 요청을 검증하고 로직에 요청을 전달하는 일과 로직에서 전달된 응답을 적절한 뷰에 연결짓는 것 역시 제어 계층의 몫이다.
손님이 바다가재 요리를 요청했을 때 종업원은 그 요리가 서비스 가능한 것인지 또한 누구에게 시키면 되는지를 알고 있어야 한다는 뜻이다. 요청을 전달받은 요리사가 바다가재 요리를 주면 그것을 식탁까지 운반해 주는 것 역시 종업원의 몫이다. UI 검증, 요청 및 응답 전달, 로직에서 던져진 예외 처리, 도메인 모델을 뷰와 연결하기 등의 고유 기능 외에는 어떤 기능도 포함하지 않는다.
◆ 대안 기술 : 현재 WAF들은 대부분 제어 계층의 핵심 기능을 포함한다. 터빈이나 에스프레소 등이 선전하고 있지만, 스트럿츠와 웹워크가 대세라고 생각된다. 당분간 별다른 대안 기술이 등장할 가능성은 적다. 오히려 스트럿츠를 확장시켜 자사 고유의 프레임워크로 최적화 시키는 작업이 활발히 진행될 것이다.
◆ 주요 패턴 : Front Controller 패턴, Service to Worker 패턴(또는 Command 패턴), Intercepting Filter 패턴, Application Controller & Context Object 패턴
- 비즈니스 로직 계층
◆ 역할 : 비즈니스 로직은 말 그대로 핵심 업무를 어떻게 처리하는지에 대한 방법을 기술하는 곳이다. 식당에서 종업원이 고객의 요구를 전달해 주면, 재료를 이용해 요리를 만드는 요리사라고나 할까? 비즈니스 로직 계층은 애플리케이션에서 가장 재사용될 확률이 높은 요소이기 때문에 신경 써서 설계해야 한다.
◆ 기능 : 비즈니스 로직에는 핵심 업무 로직의 구현과 그에 관련된 데이터의 적합성 검증 외에도 다양한 부가적인 구현이 추가된다. 트랜잭션 처리라든가, 다른 계층들과 통신하기 위한 인터페이스를 제공한다거나, 해당 계층의 객체들간의 관계를 관리하는 것 등이 그것이다.
비즈니스 로직 계층에 있어야 할 코드들이 프리젠테이션 계층이나 퍼시스턴스 계층에 여기저기 흩어져 있는 애플리케이션을 찾아보기란 그리 어려운 일이 아니다. 이런 구조는 각각의 계층을 모호하게 만들어 유지보수시 많은 시간을 필요로 하게 만든다.
가장 신경 써서 개발해야 할 비즈니스 로직에 그동안 신경을 쓰지 못했다는 것. 프리젠테이션 계층과 퍼시스턴스 계층 사이의 다리 역할을 충실히 하도록 함으로써 애플리케이션에 유연성을 더하는 것. 그것이 스프링이 탄생하게 된 배경이라고 할 수 있다.
◆ 대안 기술 : 지금까지 비즈니스 로직의 구현은 크게 EJB를 사용하는 것과 일반 자바 객체(POJO)를 사용하는 것으로 나눌 수 있었다. EJB를 사용하는 경우 개발자들의 많은 불만이 EJB 3.0을 사용함으로써 해결되리라 예상된다. 하지만 해외를 중심으로 해서 EJB를 사용하건, 사용하지 않건 비즈니스 로직들을 체계적으로 관리하는 IoC 컨테이너에 대한 관심이 증가하고 있는 추세이다. IoC 컨테이너에 대해서는 뒤에서 다시 자세히 살펴보도록 하겠다.
◆ 주요 패턴 : Business Delegate 패턴, Session Facade 패턴, Service Locator 패턴, Application Service 패턴, EJB Home Factory 패턴
- 퍼시스턴스 계층
◆ 역할 : 퍼시스턴스 계층은 데이터 처리를 담당하는 계층이다. 주로 데이터의 생성/수정/삭제/선택(검색)과 같은 CRUD 연산을 수행하게 된다. 식당으로 보자면 주방장이 사용할 재료를 담당하는 재료 담당자라고나 할까? 이 데이터는 주로 데이터베이스에서 처리되는 경우가 많아, 영속성을 의미하는 퍼시스턴스 계층이란 용어를 사용했다. 하지만 데이터가 처리되는 다른 업무 시스템이나, 웹 서비스, XML, 파일 시스템 등을 모두 고려한다면 레거시 개념을 갖는 EIS 계층이란 표현이 더 적합할 것이다.
◆ 기능 : 이 계층에서 수행하는 일은 관계형 정보를 저장하고, 수정/삭제하는 것과, 그러한 일을 수행하는 데 필요한 질의문을 관리하는 것, 그리고 가져온 관계형 정보를 객체화시키는 일이다.
◆ 대안 기술 : EJB 사용에 있어서 개발자들이 가장 불만스러워 하는 것은 CMP 방식의 엔티티 빈일 것이다. 그러한 불만은 객체 관계 맵핑(ORM)을 이용한 JDO라는 대안기술을 탄생시켰고, 또한 하이버네이트라는 또 하나의 오픈소스 기술을 실무로 끌여들였다. JDBC를 이용한 DAO 객체를 구성하는 방법도 소규모 애플리케이션에서는 여전히 인기를 끌고 있다. EJB 3.0과 JDO/하이버네이트, 그리고 JDBC를 이용한 POJO 방식 중 어떤 것이 개발자들에게 낙점될 지는 아직 미지수다.
◆ 주요 패턴 : Data Access Object 패턴, Domain Store 패턴, Sequence Blocks
- 도메인 모델 계층
◆ 역할 : 도메인 모델은 각 계층 사이에 전달되는 실질적인 비즈니스 객체라고 할 수 있다. 식당을 예로 든다면, 음식이 담긴 그릇이라고 비유할 수 있겠다.
◆ 기능 : 도메인 모델 계층은 흔히 데이터 전송 객체(DTO) 형태로 개발자가 직접 제작해서, 리퀘스트나 세션과 같은 컨텍스트에 담아 넘기게 된다. 하지만 데이터베이스의 모든 정보를 일일이 객체로 만드는 것은 귀찮을 뿐 아니라, 계층간의 통신 과정에서 데이터가 유실될 위험도 있기 때문에 최근에는 도메인 모델을 서비스로 제공하여 자동화하는 경우가 많다.
◆ 주요 패턴 : Data Transfer Object 패턴, Value List Handler 패턴
지금까지 엔터프라이즈 시스템을 구축하기 위해 일반적으로 사용되는 다섯 계층에 대해 간단히 정리해 보았다. 뻔한 이야기들을 길게 늘여 쓴 이유는 2가지 사실을 강조하기 위해서이다. 첫째, 각각의 계층은 저마다의 분명한 역할이 존재하며, 그 역할을 충실히 수행할 수많은 대안기술(Alternative)들 사이에서 개발자는 무엇을 선택할 지 결정을 내려야 한다. 둘째, 각각의 기술들은 독립적으로도 충분한 가치를 지니고 있지만, 가장 장점을 발휘하는 제 위치에서 서로 연계되어 사용될 때 그 시너지 효과가 더욱 크다.
약한 결합도를 가진 아키텍처 구성
이 글을 읽는 상당수의 독자들은 애플리케이션을 개발할 때 스트럿츠를 사용해 본 경험이 있을 것이다. 프리젠테이션 계층에는 태그 라이브러리가 접목된 JSP를 이용했을 것이며, 업무 로직과 영속성 처리는 그 규모에 따라 POJO나 EJB를 적절히 섞어 사용했을 것이다. 하지만 정말 스트럿츠만으로 충분했었는지 묻고 싶다.
출처: https://postitforhooney.tistory.com/entry/Spring-MVC-패턴에서의-5가지-계층에-대한-정보-퍼옴 [PostIT]
