상세 컨텐츠

본문 제목

프로 ASP.NET MVC 프레임워크(Pro ASP.NET MVC Framwork) - MVC 강좌 #2

전체 출간 도서

by 비제이퍼블릭 2009. 9. 18. 08:30

본문



현재 10월 중(다음달)으로 번역서가 출간될 Apress의 프로 ASP.NET MVC 프레임워크(Pro ASP.NET MVC Framwork)를 출판사의 압박!으로 열심히 번역하고 계신 김태영(태오)님과 송원석(송군)님이 운영자이자 운영진으로 계신 Taeyo.net에서 작년(2008년)에 태오님께서 올리신 MVC 관련 강좌를 발견하였습니다. 4회까지 연재를 하신 것 같으신데, 모두 올려드리도록 하겠습니다. 원본은 다음 링크에서 확인 가능합니다.

강좌 #2 [바로가기]

웹 폼 기반의 개발과 MVC 기반의 개발


 

M/V/C 로의 분리

우선 웹 애플리케이션의 구조를 Model(모델), View(뷰), Controller(컨트롤러)로 분리하는 MVC 패턴에서 각각의 그러한 컴포넌트들의 역할에 대해서 먼저 살펴보도록 하겠습니다. 각각의 분리는 물리적인 분리라기 보다는 논리적인 분리임을 기억하시고 다음 내용을 살펴보시기 바랍니다.

Model(모델)

모델은 실제 로직을 구현하는 애플리케이션의 중요한 부분입니다. 이는 일반적으로 데이터베이스로부터 데이터를 가져와서 담아두거나, 데이터베이스로 저장하는 역할을 수행합니다. 주로 모델링을 통해서 산출된 엔터티들이 이러한 모델에 속하게 되지만, 작은 규모에서는 DataSet도 모델로서 사용될 수 있습니다.

View(뷰)

뷰는 사용자 인터페이스 즉, UI을 출력하는 컴포넌트입니다. 일반적으로 UI는 모델의 데이터를 기반으로 만들어집니다. 화면 출력과 관계된 로직을 포함할 수는 있지만, 사용자 입력이나 인터렉션, 업무와 관계된 로직은 결코 View가 가져서는 안됩니다. 이는 오로지 화면을 출력하기 위한 역할만을 담당하기 때문입니다.

Controller(컨트롤러)

어찌 보면 MVC에서 가장 핵심이 되는 컴포넌트입니다. 사용자의 인터렉션을 처리하고, 모델을 조작하며, 최종 UI로 출력될 뷰를 결정하는 역할을 담당합니다. 전체적인 코디네이터 역할을 한다고 볼 수 있는데요. 이는 사용자의 입력 값을 수신하고 데이터 모델을 통해서 필요한 데이터를 가져와 응답(Response)을 구성하는 전반적인 책임을 담당합니다.

이러한 MVC 패턴에 따라 애플리케이션을 3개의 컴포넌트로 나누어 구성하게 되면, 각 요소 간에 연결을 보다 느슨하게 구성할 수가 있게 되기에 복잡한 애플리케이션을 관리하기에 용이하며, 병행 개발(동시에 각각의 컴포넌트를 개발하는 방식)이 가능하다는 장점이 있습니다. 그리고, 이러한 분리로 인해 기존의 ASP.NET 애플리케이션보다 훨씬 테스트하기가 용이하다는 이점을 얻을 수도 있습니다.

기존 ASP.NET 애플리케이션은 테스트를 하기 위해서 사용자 입력에 따라 전반적인 ASP.NET의 프로세스(페이지 클래스를 생성, 초기화하고, 개체 트리에 속해있는 모든 컨트롤들을 생성하는 등) 를 모두 거쳐가며 테스트해야 했기에 그 절차가 약간 복잡했고 또한, 테스트를 위해서는 반드시 웹 서버가 요구된다는 제약이 있었지만, MVC 패턴을 적용해서 구성하게 되면 개별적인 컴포넌트를 독립적으로 테스트할 수 있게 되기에 애플리케이션의 개발과 테스트가 상대적으로 용이하다는 이점을 얻을 수 있으며, 이는 TDD(Test-Driven Development)에도 부합한다고 볼 수 있습니다.

어떻게 모듈을 나눠야 하고, 어떤 코드를 어디에 작성해야 하는 지는 지금 고민하지 않아도 됩니다. 그에 대한 템플릿과 규칙을 ASP.NET MVC 프레임워크가 제공하고 있기에 그가 제안하는 규칙에 따라 개발을 하면 되기 때문이지요. 이에 대한 본격적인 이야기는 다음 강좌부터 시작합니다.

웹 폼 기반의 개발과 MVC 기반의 개발

조금쯤은 새로 사귄 친구의 편을 들어 설명하다 보니, 자칫하면 이러한 설명이 마치 기존의 ASP.NET 애플리케이션은 그다지 매력이 없고 MVC만이 훌륭한 것처럼 느껴지게 설명한 것도 같은데요. 앞에서도 말씀 드렸지만, 그게 꼭 그런 것만은 아닙니다. 기존 웹 폼 방식의 ASP.NET도 많은 장점들을 가지고 있으니까요. 말이 나온 김에 간단하게 두 기술이 가진 각각의 장점을 간략하게 정리해 보도록 하겠습니다.

웹 폼 기반의 웹 애플리케이션의 장점

  • 각각의 페이지 단위로 기능을 작성하는 Page Controller 패턴을 사용한다.
    : 개별 화면 단위 중심적인 업무를 개발하기에 매우 적합하다.
  • 이벤트 중심의 프로그래밍 모델을 제공한다.
    : 다양한 이벤트를 제공하는 수 많은 서버 컨트롤이 제공되기에, 이벤트 중심적인 개발을 통해 업무 화면을 직관적으로 작성할 수 있다.
  • 뷰상태(ViewState)와 서버 기반의 폼을 사용하기에, 상태 정보를 관리하기에 용이하다.
  • MVC 기반의 웹 애플리케이션의 장점

  • 모든 요청을 단일 컨트롤러를 통해서 처리하는 Front Controller 패턴을 사용한다
    : 모든 요청을 단일 컨트롤러를 통해 처리하므로, 라우팅(routing) 하부구조를 지원하는 애플리케이션을 개발할 수 있다.
  • 애플리케이션을 3개의 논리 모듈로 분리하기에 애플리케이션의 복잡성을 관리하기 쉽게 한다.
  • 뷰상태나 서버 기반의 폼을 사용하지 않는다
    : 개발자가 애플리케이션의 동작방식을 전체적으로 제어할 수 있으므로 세밀하게 애플리케이션을 조작하고 싶은 이들에게 적합하다. 단, 이러한 기능(상태정보 관리)이 필요할 경우 추가적인 작업이 요구된다.
  • 이제 MVC 모델이 어떻게 우리를 즐겁게 해줄 수 있을 것인지 개념적으로는 약간의 기대가 충전되었을 것이라 생각합니다. 막상 사용하다 보면 웹 폼 기반의 개발이 그리워지는 경우도 적지 않지만(이벤트 프로그래밍 모델도 꽤나 개발에 편리한 모델이기에), MVC는 MVC대로 유용한 많은 기능들을 제공하기에 이를 통한 개발이 한동안은 꽤 선전하지 않을까 예상이 됩니다. 물론, 그렇다 하더라도 많은 애플리케이션은 여전히 웹 폼 기반으로 개발될 것이며, 심지어는 웹 폼 기반과 MVC 기반이 혼합되는 애플리케이션도 생겨날 수 있겠지만 말입니다.

    그렇다면, 이러한 지식을 머리에 담아두고, 다음 강좌부터는 본격적으로 ASP.NET MVC 프레임워크가 지원하는 기능들에 대해서 설명을 해보도록 하겠습니다. 프레임워크에서 지원하는 기능을 간략하게 살펴본 뒤, 그에 따라 가벼운 샘플 애플리케이션을 모델/뷰/컨트롤로로 분리하여 전체적인 구동 예제를 완성하는 식으로 강좌를 진행해 볼까 합니다.

    기대가 되신다면~ Talk 게시판에 응원의 글을 남겨주십시오!!! 감사합니다.




    관련글 더보기

    댓글 영역