3.4 JSP Application Design with MVC
JSP technology can play a part in everything from the simplest web application,
such as an online phone list or an employee vacation planner, to full-fledged
enterprise applications, such as a human-resource application or a sophisticated
online shopping site. How large a part JSP plays differs in each case, of course.
In this section, I introduce a design model called Model-View-Controller (MVC),
suitable for both simple and complex applications.
JSP 기술은 전화번호부나 직원휴가일정과 같은 간단한 웹어플리케이션에서부터
구인구직, 정교한 쇼핑몰 등의 성숙한 기업 어플리케이션에 이르기까지 모든 분야에서
유용하다. .. 나는 간단하거나 복잡한 어플리케이션에 모두 적합한 모델-뷰-컨트롤러
(MVC: Model-View-Controller) 라는 설계 방법을 소개하려고 한다.
MVC was first described by Xerox in a number of papers published in the late
1980s. The key point of using MVC is to separate logic into three distinct units:
the Model, the View, and the Controller. In a server application, we commonly
classify the parts of the application as business logic, presentation, and
request processing. Business logic is the term used for the manipulation of an
application's data, such as customer, product, and order information.
Presentation refers to how the application data is displayed to the user, for
example, position, font, and size. And finally, request processing is what ties
the business logic and presentation parts together. In MVC terms, the Model
corresponds to business logic and data, the View to the presentation, and the
Controller to the request processing.
MVC는 제록스가 80년대말 발표한 여러 논문에서 처음 설명되었다. MVC 의 핵심은
프로그램로직을 세 개의 유닛 [ 모델, 뷰, 콘트롤러 ] 로 분리하는 것이다.
서버어플리케이션에서는 [ 비즈니스로직, 프레젠테이션, 리퀘스트프로세싱 ] 으로
어플리케이션 구성요소를 분류한다. 비즈니스로직은 고객,상품,주문 정보등과 같은
어플리케이션 데이터의 처리를 말할 때 쓰는 용어이다. 프레젠테이션은 이러한
데이터가 사용자에게 어떻게 보여지느냐를 의미한다. 예를들어 데이터의 위치,
글자의 종류나 크기 등을 말한다. 마지막으로 리퀘스트프로세싱은 비즈니스로직과
프레젠테이션 영역을 연결해주는 부분을 말한다. MVC 용어에 있어서, 모델은
비즈니스로직과 데이터에, 뷰는 프레젠테이션에, 콘트롤러는 리퀘스트프로세싱에
해당된다.
Why use this design with JSP? The answer lies primarily in the first two elements.
Remember that an application data structure and logic (the Model) is typically
the most stable part of an application, while the presentation of that data
(the View) changes fairly often. Just look at all the face-lifts many web sites go
through to keep up with the latest fashion in web design. Yet, the data they
present remains the same. Another common example of why presentation should be
separated from the business logic is that you may want to present the data in
different languages or present different subsets of the data to internal and
external users. Access to the data through new types of devices, such as cell
phones and personal digital assistants (PDAs), is the latest trend. Each client
type requires its own presentation format. It should come as no surprise, then,
that separating business logic from the presentation makes it easier to evolve an
application as the requirements change; new presentation interfaces can be
developed without touching the business logic.
왜 JSP 를 가지고 이렇게 설계를 할까? 그 답은 우선 앞의 두 요소에 있다.
어플리케이션 데이터구조와 로직(모델)은 전형적으로 가장 안정된 영역이고, 반면에
그러한 데이터의 프레젠테이션(뷰)은 사실 자주 변경된다는 점을 상기해보자. 단지
웹디자인의 최근 유행을 따르기 위해 많은 웹싸이트가 겪는 모든 성형수술을
주목해보자. 그러나 웹싸이트가 보여주는 데이터에는 변함이 없다. 프레젠테이션
로직이 비즈니스로직에서 분리되어야 하는 또 다른 평범한 예로, 국내외의
사용자에게 다양한 언어로 데이터를 보여주고 싶을 수 있다. (역자 주: 이 경우는
동일 템플릿에 다른 데이터할당을 말하는 것 같습니다.) 핸드폰이나 PDAs 와 같은
새로운 장치들에 대한 데이터처리는 최근의 경향이다. 각 클라이이언트 유형은
그에 맞는 프레젠테이션 포맷을 요구한다. 그렇다면, 비즈니스로직과
프레젠테이션을 분리함으로써 이러한 요구의 변경에 따라 어플리케이션을
진화시키기 쉽다는 것은 놀라운 일이 아니다. 비즈니스로직을 변경하지 않고 새로운
프레젠테이션 인터페이스를 개발할 수 있다.