ASP.NET MVC 모델에서는 (Views 폴더의) 모든 웹 리소스에 대한 직접 요청을 막아 두었다
사용자 화면(뷰)에 해당하는 Views 폴더에 있는 모든 aspx 파일에 대한 다음과 같은 요청은
모두 404 Not Found 로 처리된다
http://yourdomain.com/Views/Index.aspx
이것은 기존 웹폼 모델과 대조되는 면으로,
ASP.NET MVC에서의 사용자 화면(뷰)은 모두 컨트롤러에 의해 선택되고 랜더 되게 하기 위함이다
따라서 리소스에 대한 직접 요청은 의도적으로 막고 있는 것이다
Views 폴더의 Web.config 에 정의된 HttpNotFoundHandler
Visual Studio 에서 ASP.NET MVC 프로젝트를 생성하면 총 두개의 Web.config 가 생성된다
루트에 있는 Web.config 는 기존과 같이 응용프로그램 전역적인 설정 파일이며
Views 폴더의 Web.config 는 Views 폴더에만 적용되는 설정 파일인데, 이 파일에 정의된
HttpNotFoundHandler 가 리소스 직접 요청에 대한 Not Found 처리를 하는 HttpHandler 이다
<add path="*" verb="*" type="System.Web.HttpNotFoundHandler"/>
</httpHandlers>
위와같이 정의된 핸들러에 의해 Views 폴더의 aspx 파일을 포함한 모든 직접 요청은 404로 처리된다
참고로 ASP.NET 웹폼 모델에서는 *.aspx 에 대한 처리는 System.Web.UI.PageHandlerFactory 라는
핸들러에 의해 처리되었다
HTTP 핸들러에 대한 개념과 기본 등록된 핸들러 정보는 다음 링크에서 확인할 수 있다
[ASP.NET] HTTP Handler
[ASP.NET] HttpHandler- Demo
[ASP.NET] Machine.config 미리 정의된 HttpHandler
ASPX 파일만 막기
기본 구성으로는 Views 폴더의 모든 리소스에 대한 직접 접근을 막고 있다
경우에 따라서는 Views 폴더에 ASPX 외에 다양한 웹 리소스가 위치할 수 있다
예를 들어 이미지파일이나 css, js 파일, pdf 파일 등을 들 수 있다
이러한 웹 리소스에 대한 직접 요청은 정상적으로 되길 원할 수도 있다
그렇다면 핸들러 정보를 다음과 같이 수정하여 ASPX 파일만 막도록 하면 된다
<add path="*.aspx" verb="*" type="System.Web.HttpNotFoundHandler"/>
</httpHandlers>
그러나 ASP.NET MVC 모델에서는 뷰를 제외한 기타 웹 리소스를 Views 폴더에 두지 않기를 권장한다.이미지나 CSS, JS 와 같은 정적이고 공개적인 웹 리소스들은 자동으로 생성된 Content 폴더에 두는 것이다
참고: http://haacked.com/archive/2008/06/25/aspnetmvc-block-view-access.aspx
'.NET Framework' 카테고리의 다른 글
| Razor 구문 (0) | 2011.07.19 |
|---|---|
| ASP.NET Razor (5) | 2010.12.13 |
| ASP.NET MVC, 폼 데이타 전송하기 (0) | 2010.08.06 |
| ASP.NET MVC 에서 요청 매개변수 넘기기 (0) | 2010.08.05 |
| ASP.NET MVC, Hello World (1) | 2010.08.04 |
앞서 ASP.NET MVC 에서 요청 매개변수 넘기기 에서는 URL 질의 방식에 ASP.NET MVC이
어떻게 반응하는지 알아 보았다. URL에 매개변수를 전달하는 방식은 GET 요청에 해당한다
이번에는 ASP.NET MVC이 POST 요청을 어떻게 처리하는지 알아 보도록 하자
POST 요청의 보편적인 모습은, HTML 입력 양식을 이용한 폼 데이타 제출이다
이 글에서는 간단한 회원가입 폼을 POST 로 전송하고 이를 처리하는 방법을 다룬다
ASP.NET MVC 프로젝트를 하나 생성하고 컨트롤러에 엑션 메서드를 하나 추가한다
- HomeController.cs 에 액션 메서드 추가하기
public ActionResult RegisterForm()
{
return View();
}
- 회원 가입 페이지 (뷰) 생성하기
그리고 이 액션 메서드에 해당하는 뷰를 생성한다
생성된 RegisterForm.aspx 뷰 페이지는 회원가입 입력 양식을 아래와 같이 정의한다
<body>
<h1>회원가입</h1>
<form action="/Home/RegisterForm" method="post">
<p>아이디: <input type="text" name="MemberID" /></p>
<p>비밀번호: <input type="password" name="Password" /></p>
<p>닉네임: <input type="text" name="NickName" /></p>
<p>이메일: <input type="text" name="Email" /></p>
<input type="submit" value="가입하기" />
</form>
</body>
전형적인 폼 양식이다. 이제 프로젝트를 빌드하고 페이지를 호출해 보자
http://localhost:11102/Home/RegisterForm
- 모델 정의 하기
아직 폼 데이터를 처리 할 수 있는 것은 아니다. 회원정보에 해당하는 자료형을 모델로 정의해 보자.
이 모델을 기반으로 폼 데이터가 처리될 것이며 결과 뷰역시 이 모델을 기반으로 작성될 것이다
프로젝트의 Model 폴더에 Member.cs 라는 클래스를 만들고 다음과 같이 작성한다
이때 RegisterForm 뷰에서 정의한 폼 요소들의 Name 속성과 일대일 대응하도록 속성명을 정의하자
public class Member
{
public string MemberID { get; set; }
public string Password { get; set; }
public string NickName { get; set; }
public string Email { get; set; }
public void Submit(){
//멤버정보를 DB에 입력하는 등의 실제 작업을 처리한다
}
}
- 컨트롤러 수정하기
그리고 폼 데이타 수신을 위해 컨트롤러를 다음과 같이 수정한다
AcceptVerbs 어트리뷰트를 통해 GET 과 POST 요청을 직접 명시한다
이렇게 하면 get, post 요청에 적절한 액션메서드가 선택될 것이다
즉 동일한 {controller}/{action} 요청이지만 get, post 요청에 따라 (이름은 같지만) 다른 메서드가
호출되는 것이다
또한 각 액션 메서드의 반환 값을 보면,
get 요청에는 기본 뷰인 RegisterForm.aspx 가 랜더되도록 했으며(return View();),
post 요청에는 명시적으로 이름을 지정하여 RegisterComplete.aspx 뷰가 랜더되도록 하였으며
mebmer 객체를 뷰로 전달하고 있다
(return View("RegisterComplete", member))
그리고 post 요청에 해당하는 액션 메서드의 매개변수를 주의깊게 보자
모델에서 정의한 Member 객체를 post 메서드의 매개변수로 취하고 있다
ASP.NET MVC '모델 바인딩 매커니즘'은 폼 전송으로 전달된 데이터의 키(Key) 정보를 바탕으로
Member 객체의 속성명에 일대일 매칭시켜 값을 자동으로 바인딩 시켜 준다
즉 <input type=text name=MemberID>의 값이 Member.MemberID 로 자동 바인딩이 된다는 말이다
public class HomeController : Controller
{
[AcceptVerbs(HttpVerbs.Get)]
public ActionResult RegisterForm()
{
return View();
}
[AcceptVerbs(HttpVerbs.Post)]
public ActionResult RegisterForm(Member member)
{
member.Submit();
return View("RegisterComplete", member);
}
}
- 강력한 형식의 뷰 만들기 (회원가입 완료 페이지(뷰) 생성하기)
이제 회원가입 완료 페이지에 해당하는 RegisterComplete 뷰를 생성해 보자
Controller 아무 영역에다 대고 마우스 우클릭 -> Add View 해서 뷰를 생성하는데
아래 그림과 같이 'Create a strongly-typed view' 를 선택해서 모델로 정의했던
Member 클래스를 View data class 로 선택하도록 한다
이렇게 특정 클래스를 기반으로 강력한 형식의 뷰를 만들게 되면
View data class에 정의된 객체를 뷰에 직접 랜더링 할 수 있게 된다
그리고 생성된 RegisterComplete.aspx 는 다음과 같이 작성한다
이 뷰는 강력한 형식으로 생성된 뷰이기 때문에 Model 이라는 키워드를 통해 직접 모델 데이터에
접근할 수 있게 된다. 아래 코드는 폼 데이터로 전송되어 모델 객체에 바인딩 된 값을 다시 결과 화면에
뿌리고 있는 것이다
<body>
<h1>회원가입을 축하드립니다</h1>
<p>아이디: <%= Model.MemberID %></p>
<p>닉네임: <%= Model.NickName %></p>
<p>이메일: <%= Model.Email %></p>
</body>
'.NET Framework' 카테고리의 다른 글
| ASP.NET Razor (5) | 2010.12.13 |
|---|---|
| 웹 리소스 요청 막기, HttpNotFoundHandler (0) | 2010.08.09 |
| ASP.NET MVC 에서 요청 매개변수 넘기기 (0) | 2010.08.05 |
| ASP.NET MVC, Hello World (1) | 2010.08.04 |
| 벌써 ASP.NET MVC 3 ? (0) | 2010.08.03 |
이전 ASP나 ASP.NET 웹폼 모델에서는 URL의 꼬리표에 붙여 있는 매개변수를
Request 객체를 통해전달 받을 수 있었다
즉 다음과 같이 두 개의 매개변수를 URL 에 붙여서 매개변수를 전달하게 되면,
요청 URL: http://yourdomain/main.aspx?param1=value1¶m2=value2
아래처럼 매개변수 정보를 취할 수 있다(ASP.NET 기준)
string value1 = Request.QueryString["param1"].ToString();
string value2 = Request.QueryString["param2"].ToString();
그렇다면 ASP.NET MVC 모델에서는 매개변수를 어떻게 전달하고 받는지 알아보도록 하자
기본은 동일하다
ASP.NET MVC 역시 이전 웹폼 모델과 동일한 형태로 매개변수를 넘기고 받을 수 있다
즉 아래와 같이 요청 URL 에 ? 꼬리표로 매개변수를 전달하면
HomeController 의 Index 액션 메서드에서 다음과 같이 매개변수에 접근할 수 있게 된다
요청 URL: http://localhost:11102/Home/Index/?name=Park&age=10
public ActionResult Index()
{
string name = Request.QueryString["name"].ToString();
string age = Request.QueryString["age"].ToString();
ViewData["param"] = String.Format("Hello, {0}, Your age {1}", name, age);
return View();
}
액센메서드의 매개변수로 전달 받기
URL 에 포함되어 있는 매개변수를 액션 메서드의 매개변수로 전달 받을 수도 있다
아래 코드는 Index 매개변수를 통해 URL로 전달되는 매개변수를 전달 받고 있다
요청 URL: http://localhost:11102/Home/Index/?name=Park&age=10
public ActionResult Index(string name, string age)
{
ViewData["param"] = String.Format("Hello, {0}, Your age {1}", name, age);
return View();
}
액션 메서드를 통해 매개변수를 전달 받는 것은 ASP.NET MVC 프레임워크에서 제공해 주는 기능이며
이전 형태 보다는 조금 더 ASP.MVC 스럽다고 할 수 있겠다
액션 메서드로 매개변수를 전달 받을 경우 URL 에 정의된 매개변수 명과 액션메서드에 정의된
매개변수 명이 동일해야 한다는 규칙이 있다(순서는 상관 없다. 변수 이름이 중요하다)
참고로 URL 에 매개변수가 있다고 해서 반드시 액션 메서드에 매개변수를 정의 해야 하는 것은 아니다
그리고 그 반대의 경우, 즉 액션메서드에 매개변수가 정의 되었다고 해서 반드시 URL에 매개변수를 넘겨야 하는 것은 아니다 (물론 이 두 경우는 매개변수를 사용하지 않을 경우이다)
예를 들어 URL 에 매개변수가 생략되었을 경우 액션메서드로는 null 을 전달하게 될 것이다
URL 스키마 사용자 정의
앞서 Request.QueryString 으로 매개변수를 가져오는 방식에 비해 액션 메서드의 매개변수로 가져오는 것이 보다 깔끔하고 직관적이라는하다는 것을 느낄 수 있다.
이것은 매개변수를 가져오는 측면에서 ASP.NET MVC 가 지원해 주는 부분이 되겠다
이번에는 매개변수를 전달하는 측면에서의 ASP.MVC 의 장점을 살펴 보자
앞서 요청 URL은 다음과 같은 스키마로 이루어 졌었다
http://localhost:11102/Home/Index/?name=Park&age=10
전통적인 방식으로 URL에 ? 꼬리표를 통해 매개변수를 전달하고 있다
우리는 이러한 요청 URL을 보다 깔끔하게 변경하고 싶다
ASP.NET MVC 에서는 URL 스키마를 개발자의 입맛대로(?) 재 구성할 수 있는 방법을 제공해 준다.
이는 ASP.NET MVC의 라우팅 엔진이 제공해 주는 기능인데,
Global.asax 의 RegisterRoutes 메서드의 커스트마이징을 통해 구현할 수 있다
우선 매개변수를 어떤 형태의 URL 스키마로 정의할 지 결정해야 하는데,
다음과 같이 '/(슬래쉬)'를 계속 이어가고 싶다고 가정해 보자
http://localhost:11102/Home/Index/매개변수1/매개변수2
이와 같은 URL 스키마를 실현하기 위해 Global.asax 파일에 정의된
RegisterRoutes 메서드를 약간 수정해 보자
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default",
"{controller}/{action}/{name}/{age}", // URL with parameters
new { controller = "Home", action = "Index",
name = UrlParameter.Optional,
age = UrlParameter.Optional }
);
}
MapRoute 메서드의 두 번째 정보에 URL 스키마를 정의한다
우리가 결정한 URL 스키마를 실현하기 위해 /(슬래시)로 매개변수를 취할 수있도록 하였다
컨트롤러/액션메서드/name매개변수/age매개변수 형태로 정의함
=> "{controller}/{action}/{name}/{age}"
그리고 다음과 같이 각 매개변수의 옵션 여부를 지정하였다
이는 name, age 정보가 URL에서 생략될 수 있다는 의미이다
name = UrlParameter.Optional,
age = UrlParameter.Optional
이제 구성이 완료 되었으니 다음과 같은 요청에 정상적으로 반응하게 될 것이다
http://localhost:11102/Home/Index/Park/10
만일 다음과 같은 URL을 원한다면,
http://localhost:11102/Home/Index/Park-10
다음과 같이 정의하면 된다
"{controller}/{action}/{name}-{age}"
참고로 이런 식으로 URL 스키마 재정의로 매개변수 정보를 구성하였다면,
더 이상 Request.QueryString 로 받을 수 없다는 것에 주의하자
-----------------------------------------------------------------------------------
마지막으로 URL 재구성된 상태에서 전통적인 ? 매개변수 전달을 같이 혼용하면 어떻게 될까?
다시 말해 다음과 같은 URL 요청은 어떻게 되는지 살펴 보자
요청 URL: http://localhost:11102/Home/Index/Park/10?name=Kim&age=20
액션메서드:
public ActionResult Index(string name, string age)
{
ViewData["param"] = String.Format("Hello, {0}, Your age {1}", name, age);
return View();
}
이를 경우 URL 로 재구성된 매개변수 정보가 먼저 참조 된다
즉 URL 요청으로 부터 전달되는 name, age 라는 매개변수가 각각 두 개씩 이지만
URL 재구성에 의한 name=Park, age = 10 이 전달되는 것이다
그러나 만일 URL 스키마에서 매개변수 정보를 생략하고 다음과 같이 요청 된다면,
http://localhost:11102/Home/Index/?name=Kim&age=20
결과는 ? 매개변수가 전달되게 된다
ASP.NET MVC 는 라우팅 구성 정보에 의거한 적절한 매개변수를 가져올 수 없는 경우
전통적인 ? 질의 문자열에서 매개변수를 가져오게 되는 것이다
'.NET Framework' 카테고리의 다른 글
| 웹 리소스 요청 막기, HttpNotFoundHandler (0) | 2010.08.09 |
|---|---|
| ASP.NET MVC, 폼 데이타 전송하기 (0) | 2010.08.06 |
| ASP.NET MVC, Hello World (1) | 2010.08.04 |
| 벌써 ASP.NET MVC 3 ? (0) | 2010.08.03 |
| ASP.NET MVC가 모바일 웹에 적합한 이유 몇가지 (0) | 2010.07.23 |
가장 심플한 형태의 ASP.NET MVC 를 만들어 보자
모든 개발 공부는 가장 기본적인 구조에서 부터 출발하여 기술확장, 응용력확장을 해 나가는 것이 원칙이다.
처음부터 복잡한 형태를 이해하려고 하면 진입이 어려워서 쉽게 흥미를 잃어버리기 마련이다.
따라서 ASP.NET MVC 기반의 Hello World 샘플을 제작해 보도록 한다
1. ASP.NET MVC 프로젝트 생성
Visual Studio 2008 에서 새프로젝트를 만든다
아래그림과 같이 ASP.NET MVC2 Web Application 템플릿을 선택하고 프로젝트와 솔루션 이름은
HelloWorld 로 한다
확인을 클릭하면 아래 그림과 같이 유닛테스트 프로젝트 생성 여부를 묻는데,
우리는 간단한 데모를 빨리 만들어 볼 목적이므로 생성하지 않도록 한다
이렇게 프로젝트를 생성하면 VS는 자동으로 응용프로그램을 코드와 파일들을 마련해 주는데
이 자체가 하나의 ASP.NET MVC 프로그램이 된다
바로 F5를 눌러 실행시켜 보도록 하자
그러면 아래 그림과 같이 적당히 이쁜 웹 페이지를 브라우저에서 확인할 수 있다
간단한 멤버십 기능과 Home, About 링크가 제공된다
이 차제만으로도 훌륭한 샘플 데모이지만 처음 보기에는 조금 복잡해 보일 수도 있다
우리는 자체적으로 Hello World 만 출력해 볼 목적이므로 관련 파일들을 정리하도록 한다
2. 프로젝트 자동 생성 파일 정리하기
처음 생성된 프로젝트 구조를 보면 아래 왼쪽 그림과 같이 꽤 많은 파일들이 포함되어 있다
이를 오른쪽 그림과 같이 설정파일과 폴더구조만 남겨두고 모든 파일을 삭제하자
 |
=> |  |
이렇게 파일들을 제거하고 다시 실행을 해 보면 아래와 같은 오류를 보게 될 것이다
뷰와 컨트롤러를 모두 삭제했으니 페이지를 찾을 수 없다는 오류가 난 것이다
3. 뷰와 컨트롤러 생성하기
이제 Hello World 를 화면에 출력하기 위해 뷰와 컨트롤러를 생성해 보도록 하자
ASP.NET MVC 환경에서는 모든 요청의 출발은 컨트롤러(Controller)이다
컨트롤러가 요청에 대한 적절한 처리를 수행한 뒤 특정 뷰를 선택해 랜더링 되도록 한다
따라서 먼저 컨트롤러를 생성해 보도록 하자
솔루션탐색기에 Contollers 폴더에서 추가 -> Controller 해서
다음과 같이 HomeController 를 생성한다
그러면, Controller 클래스로 부터 상속받은 HomeColtroller 클래스와 Index 라는
액션메서드가 자동 생성된다. 코드를 아래와 같이 조금 수정하도록 하자
public class HomeController : Controller
{
public ActionResult Index()
{
ViewData["param"] = "HelloWorld";
return View();
}
}
ViewData 는 컨트롤러에서 뷰로 데이터를 전달하기 위한 키/값 구조로 이루어진
Dictory 형태의 자료형이며 여기에 "Hello World" 라는 문자열을 전달하기로 한다
그리고 메서드의 반환 값으로 ActionResult 인데 Index 액션 메서드가 특정 뷰를 페이지를
랜더링 하도록 하는 것이다. 여기서는 return View()로 뷰이름을 생략하였는데 기본값으로
메서드 이름인 Index 뷰(Index.aspx)를 선택하게 되는 것이다
다음으로 Index 메서드 아무 위치에서 마우스 우클릭해서 Add View 를 선택한다
이는 HomeController 의 Index 액션메서드의 뷰를 생성하는 것이다
뷰 이름은 Index로 하고 Add를 클릭하면,
프로젝트의 Views 폴더에 Home 폴더아래 Index.aspx가 생성된다
Index.aspx 의 <body> 안에 다음의 태그를 추가하자
컨트롤러에서 전달한 데이터를 뿌려주는 것이다
<body>
<div>
<%=ViewData["param"] %>
</div>
</body>
이제 다 됐다. F5 키로 프로젝트를 실행 해 보자.
아래 그림과 같이 Hello World 가 출력되는 것을 확인할 수 있다
사실 이렇게 간단한 출력을 위해서는 굳이 View 페이지나 ViewData 자료전달이
불필요 할 수 있지만, 테스트를 위해 갖추어 봤다
* URL 라우팅 잠시 살펴보기
매우 간단한 Hello World 를 다 만들어 봤다
그런데 프로젝트를 실행해서 요청 URL을 확인해 보면 다음과 같다
http://localhost:11102/
솔루션 탐색기의 Index.aspx 파일은 /Views/Index.aspx 에 있는데 말이다
게다가 정직한(?) 형태로 다음과 같이 웹 리소스 경로 그대로를 요청하면 404 Not Found 오류가 난다
http://localhost:11102/Views/Index.aspx
이유인 즉,
ASP.NET MVC는 URL 라우팅 엔진을 포함하고 있는데 이 라우팅 엔진에 의해
URL 이 해석되고 요청에 대한 컨트롤러와 액션 메서드를 선택하여 호출하게 된다
그리고 이 액션메서드에서 뷰를 선택하도록 되어 있기 때문에 URL 구조가 이전과는
다른 형태가 되는 것이다
URL 라우팅이 URL을 어떻게 해석하고 어떤 컨트롤러에게 보내야 할지 결정하게 되는
규칙을 마련해야 하는데 이 규칙은 Global.asax 파일에 다음과 같이 정의되어 있다
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default", // Route name
"{controller}/{action}/{id}", // URL with parameters
new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
);
}
URL 규칙은 controller/action/id 형태로 이우러지며
기본값으로는 controller = "Home" , action = "Index" 로 정의되어 있다
즉 앞서 요청과 같이 (http://localhost:11102/) 컨트롤러와 액션메서드 없이 호출하게 되면
자동으로 Home 컨트롤러, Index 액션메서드가 선택되어 실행되는 것이다
따라서 위 규칙에 맞는 다음과 같은 요청은 모두 같은 것이 된다
- http://localhost:11102/ : 컨트롤러, 액션메서드 지정 없음. 기본 값 사용
- http://localhost:11102/Home : 컨트롤러 지정, 액션메서드는 기본 값 사용
- http://localhost:11102/Home/Index : 컨트롤러, 액션메더스 모두 명시함
'.NET Framework' 카테고리의 다른 글
| ASP.NET MVC, 폼 데이타 전송하기 (0) | 2010.08.06 |
|---|---|
| ASP.NET MVC 에서 요청 매개변수 넘기기 (0) | 2010.08.05 |
| 벌써 ASP.NET MVC 3 ? (0) | 2010.08.03 |
| ASP.NET MVC가 모바일 웹에 적합한 이유 몇가지 (0) | 2010.07.23 |
| ASP.NET MVC 구성도 (0) | 2010.07.23 |
표했었다. 그리고 실제로 몇 가지 테스트를 해 보았다
: ASP.NET 웹폼 페이지가 자동 생성하는 HTML 코드 보기
이 테스트의 결과는 우려에 비해서는 대략 괜찮음(?) 이었다
몇 가지를 포기하거나 사소한 것을 무시한다면, 웹폼 모델이 웹 표준에 크게 저해되지는 않겠다 싶었다
그러나 여전히 맘 속에 남아 있는 것은 그 몇가지 이다. 마치 어거지로 끼워 맞춘다는 느낌이랄까?
ASP.NET MVC 가 웹폼에 비해 모바일.. 그리고 표준 웹에 더 적합하다는 몇 가지 이유가 있다
1) 뷰스테이트(ViewState)가 없다
뷰스테이느는 히든 값으로 서버에 전송되어 웹에서 상태유지가 가능하도록 지원되는 기술 요소이다
다만 뷰스테이트는 매번 요청 시 마다 송/수신 되므로 대역폭의 낭비가 발생한다
모바일은 대역폭에 굉장히 민감한 환경이다.
전통적인 윈도우 개발 방식의 상태유지를 포기하고 대역폭을 아끼는 쪽에 한표 던진다
ASP.NET MVC 에서도 모델 바인딩 기법을 이용하면 상태는 일부 유지되기에 더 효과적이다
2) 서버컨트롤 배제
웹폼 모델은 정말 윈도우 개발방식과 많이 닮아 있다. 설계철학 자체가 그러했으니까 당연하다
웹폼의 그 수많은 서버컨트롤. 사실 매우 유용한 컨트롤들이다. 다만 기존 환경에서는.
서버컨트롤은 자동으로 HTML 코드로 대체되고 이 코드는 표준을 준수한다고 장담할 수 없다
또한 서버컨트롤에 자동으로 부여된 ID 값은 혼란스러우며 이는 곧 자바스크립트나 CSS의 연동에
일부 제약이 있다는 것을 의미한다
ASP.NET MVC 에서는 서버컨트롤을 사용하지 않는 것이 일반적이다
물론 ASP.MET MVC 차원에서 뭔가를 획기적으로 지원해 주는 것은 아니다.
서버컨트롤을 사용하지 않을 뿐이다.
서버컨트롤을 사용하지 않게 됨으로써 자동으로 생성되는 HTML로 인한 여러 상황을 염두하지 않아도
되며 ASP.NET 의 영역과 별도로 분리하여 잘설계되고 표준적인 마크업을 사용하는 편에 한표 던진다
3) JQuery 와의 연계성
ASP.NET MVC 와 JQuery는 사실 별개의 기술이지만,
ASP.NET MVC 에서는 MVC 프로젝트 템플릿의 일부로 JQuery 라이브러리를 포함시켰다
이는 ASP.NET MVC가 JQuery 와의 연계에 노력을 했다는 증거이며 표준 자바스크립트 라이브러리의
필수성을 볼 때 바람직한 모습이다.
4) 기타 부가 요소
표준 웹, 모바일 환경과 직접적인 연관은 없지만 ASP.NET MVC 만의 매력적인 장점이 있다
- 관계 분리를 통한 좋은 유지보수성
MVC 철학 자체가 묻어 있는 장점이다. 관계 분리는 각 업무 분야의 커플링을 해소해 다른 요소에
저해받지 않고 개발, 유지보수, 확장을 가능토록 해 준다
- 관계 분리로 인한 좋은 (자동) 단위 테스트 환경
관계분리는 자동화된 테스트 시나리오, 단위 요소 테스트에 매우 적합한 모델이다
- URL 라우팅 시스템
ASP.NET MVC 에서는 URL 라우팅 개념을 도입하여 깔끔한 URL 을 만들 수 있다
이는 현재 모바일 트랜드와 정확히 일치하는 철학이며 상당히 직관적인 URL의 효과가 있다
또한 이것은 REST 의 개념과 잘 들어 맞는다
- 그리고 경험. 시도.
ASP.NET MVC는 닷넷 3.5 이상에서 펼칠 수 있는 기술이다.
그만큼 최신 기술이며 MS의 전폭적인 지원이 있다. 그리고 웹폼보다는 진보된 시도라 할 수 있다
(다 알겠지만 웹폼과 MVC의 등급은 없다. 즉 어떤게 훨씬 더 좋다라는 것이 없다는 것이다.
다만 환경에 맞는 선택만 있을 뿐이다)
새로운 기술 시도, 산업 트랜드 지향 등의 경험. 시도적 측면이 좋다
'.NET Framework' 카테고리의 다른 글
| ASP.NET MVC, Hello World (1) | 2010.08.04 |
|---|---|
| 벌써 ASP.NET MVC 3 ? (0) | 2010.08.03 |
| ASP.NET MVC 구성도 (0) | 2010.07.23 |
| ASP.NET MVC 프레임워크 (0) | 2010.07.05 |
| ASP.NET 웹폼 결과페이지 검증해 보기 (0) | 2010.07.05 |
Routing System
ASP.NET MVC 프레임워크에서는 요청 URL 에 대한 라우팅 엔진을 포함하고 있다
사실 URL 라우팅은 MVC 설계 원칙과는 별개의 주제라 할 수 있다
그러나 ASP.NET MVC 프레임워크는 현재 유명하고 유용한 웹 개발 기술을 많이 채용하고 있다
URL 라우팅 역시 그러한 일환 중 하나라고 보면 되겠다
보통 웹 요청 URL은 말그대로 웹 서버의 자원를 직접 가르키도록 되어있다
예를 들면 http://mydomainxxx.com/home/default.html 형태의 URL이며
실제 웹 서버에 있는 home 폴더의 default.html 파일을 가르키는 것이다
그러나 라우팅 엔진을 이용하면 웹 서비의 물리적인 디렉터리,파일 구조와 직접 매칭되지 않아도 된다
더불어 웹 페이지에 전달되는 파라메타 정보 역시 기존의 default.html?name1=value1&name2=value2
형태처럼 지저분(?)하지 않게 되었다.
ASP.NET MVC에서 라우팅 룰(규칙)은 Global.asax 파일에 정의되어 있다
다음에 자세히 알아 보자
Controller
어찌보면 MVC 프레임워크의 중심 역할이 아닌가 한다
모든 요청은 컨트롤러(Controller)에게 전달되고 이 컨트롤러에 의해 적절한 모델과 뷰가 선택되는 것이다. 즉 모델과 뷰의 중간에서 요청을 중계, 처리하는 역할을 한다
ASP.NET MVC의 컨트롤러 클래스는 System.Web.Mvc.Controller 에서 상속받도록 한다
역시 다음에 자세히 알아 본다
Action Method
Controller 클래스에 정의된 메서드이다
컨트롤러에서 실제 요청을 처리하게 되는 메서드라 보면 된다
특정 요청은 라우팅 룰에 의해 특정 컨트롤러의 특정 메서드로 전달된다
이를 액션메서드라고 하며 이 메서드에서 요청 처리 및 뷰 선택, 데이타 전달을 수행한다
View
사용자에게 보여지는 영역이다
즉 최종 HTML 로 랜더링 되는 페이지로써 웹 브라우저에 표시되는 영역이다
HTML과 CSS, JavaScript 와 같은 클라이언트 웹 기술이 적용되는 페이지이며
<%= %> 형태의 인라인코드로 서버측의 내용을 출력하게 된다
Model
모델을 정의하는 영역이다
모든 웹 응용프로그램은 특정 데이터를 다룬다
회원가입 시 회원데이터, 게시판의 게시물 데이터, 쇼핑몰의 상품데이터 등의 데이터들이
모델영역에 정의하게 되며 이 데이터는 컨트롤러에 의해 뷰로 전달되게 된다
ViewData
컨트롤러의 액션메서드에서 특정 뷰를 랜더할 때 전달할 데이터를 저장하는 공간이다
키/값 형태의 복수값을 저장할 수 있는 Dictory 구조로 이루어져 있다
간혹 강력한 형식의 뷰를 생성할 필요도 있는데,
이는 데이터를 정의하는 모델과 명시적으로 연결시키는 구조로 생성된다
이렇게 생성된 뷰에서는 모델의 결과데이터를 Model 이라는 키워드로 직접 액세스 할 수 있게 된다
'.NET Framework' 카테고리의 다른 글
| 벌써 ASP.NET MVC 3 ? (0) | 2010.08.03 |
|---|---|
| ASP.NET MVC가 모바일 웹에 적합한 이유 몇가지 (0) | 2010.07.23 |
| ASP.NET MVC 프레임워크 (0) | 2010.07.05 |
| ASP.NET 웹폼 결과페이지 검증해 보기 (0) | 2010.07.05 |
| ASP.NET 웹폼 페이지가 자동 생성하는 HTML 코드 보기 (0) | 2010.07.05 |
HTML5 기반 웹 사이트 개발 시 서버측 기술을 고민하다 ASP.NET MVC 패턴을 떠올리게 되었다
http://mobilepp.tistory.com/3
기존 ASP.NET 의 웹폼(Web Form) 모델의 표준 HTML 코드 생성에 의문이 생기기 시작하면서...
서버컨트롤 없는 ASP.NET 페이지, 즉 이전 ASP와 유사하게 요청에 대한 처리만 서버페이지에서
담당하고 프리젠테이션 부분은 <% ... %> 블럭 내 처리를 해 보는 것을 생각해 보았다
그러던 중, 서버컨트롤 및 뷰스테이트 등에 의존하지 않은 모델인 MVC를 떠올리게 되고
ASP.NET MVC 프레임워크로 자연스레 눈이 가게 되었다
물론 MVC 패턴과 서버컨트롤의 사용 유/무와는 무관하다
MVC 패턴 자체가 닷넷의 기술도 아니고 MS에서 만든 패턴도 아니다
이는 모델과 뷰, 그리고 이를 중재하는 컨트롤러의 명확한 구분으로 각 부문간 커플링을 제거하고 효율적이고 유지/보수성이 좋은 개발환경을 위한 패턴이다
MS에서 만든 ASP.NET MVC 프레임워크는 MVC 패턴 구현을 위한 도구적 지원에 가까우며
그 가운데 서버컨트롤의 사용이 배제되는 것이다
어찌되었던 기존 ASP.NET 으로 표준 웹 사이트를 개발하고 싶은 나의 요구사항은
서버컨트롤의 사용을 배제하고 싶은 쪽으로 기울어졌고 여기에 더불어 효과적인 웹 개발 패턴이 어울어지며 이를 도구차원에서 지원해 주는 ASP.NET MVC 프레임워크의 선택으로 가닥이 잡히고 있는 것이다
ASP.NET MVC 프레임워크를 인터넷에서 잠시 훓어 보니, 생각했던것보다 매력적임을 느끼고 있다
재미있는 기술은 나의 인생을 바쁘게 만들지만 흥미롭게도 만든다
'.NET Framework' 카테고리의 다른 글
| 벌써 ASP.NET MVC 3 ? (0) | 2010.08.03 |
|---|---|
| ASP.NET MVC가 모바일 웹에 적합한 이유 몇가지 (0) | 2010.07.23 |
| ASP.NET MVC 구성도 (0) | 2010.07.23 |
| ASP.NET 웹폼 결과페이지 검증해 보기 (0) | 2010.07.05 |
| ASP.NET 웹폼 페이지가 자동 생성하는 HTML 코드 보기 (0) | 2010.07.05 |
