안녕하세요. 아직 떨린 마음을 감추지 못하는 팀블로그 새내기 박세식입니다. 너무나 오랜만에 포스팅을 하게되네요. 제 개인사까지 다 말씀드릴 필요는 없겠지만, 여러분 모두 새해에는 하시는일 모두 잘되었으면 좋겠습니다. 진심으로요ㅠㅠ 늦었지만 새해 복 많이 받으세요^^
이번 시간은 ASP.NET MVC와 인사를 나눠보는 시간을 갖도록 하겠습니다. 반갑게 만나보도록 하죠^^
M, V, C의 각방생활
먼저 프로젝트를 생성합니다. 새 프로젝트 열기에서
ASP.NET MVC 2 Web Applicatoin 을 선택하고, 이름은 HelloMVC 로 하겠습니다. OK를 클릭하면 다음과 같이 유닛 테스트 프로젝트를 생성할 것인지 묻는 창이 뜹니다. (이게 ASP.NET MVC의 장점이라는 겁니다. 프로젝트 자체에서 유닛 테스트를 지원해주고 있습니다. 이 창에서 Yes 를 선택하면 간단하게 유닛테스트 프로젝트를 생성할 수 있습니다.) 이 시간은 유닛테스트와는 전혀 상관이 없는 관계로 No를 선택하도록 하겠습니다.
그러면, 다음과 같은 구조의 프로젝트가 생성된 것을 확인하실 수 있습니다.
Controllers, Models, Views 폴더가 각각 분리되어 생성되었습니다. 지나가는 얘기로, 저의 한가지 꿈이 여러개의 방이 있는 집을 갖는건데요.^^; 하나는 서재실, 또 하나는 음악실, 나머지 하나는 침실 뭐 이런거죠. 정말 각각의 방 안에서의 할일이란 명확합니다. 각각의 방에서 할일들을 한 방에서 하게 된다면... 잠시 상상해보겠습니다. 한쪽에서는 드럼과 피아노와 일렉기타의 절묘한 하모니의 시끄러움(?)이, 다른 한쪽에서는 책과 씨름하며, 또 다른 한쪽에서는 코를 곯며 자는 모습... 상상이 가십니까? 음악실에서는 음악을 연주하며 맘껏 소리높여 노래도 부르고, 서재실에서는 조용한 가운데 책도 보며 교양을 쌓고, 침실에서는 자면되는거죠. 모델, 뷰 그리고 컨트롤러 또한 각자의 할 일이 뚜렷하기 때문에 한 방에 같이 있을 수가 없습니다. 각방을 써야하는거죠^^
프로젝트가 생성될때 샘플페이지도 같이 생성이 됩니다. F5를 눌러서 확인해보겠습니다. 클릭하시면 디버깅을 할 수 있도록 Web.config 파일을 수정한다는 팝업창이 뜨는데요, OK하고 넘어가도록 합니다.
자, Welcome to ASP.NET MVC! 가 출력되는 것을 확인하실 수 있습니다. 우리를 먼저 반갑게 맞이해주는데요.^^ 기분좋네요~ 가만히 있을 순 없죠. 저도 인사를 해보도록 하겠습니다.
Hello! ASP.NET MVC!!!
먼저, 컨트롤러 폴더의 HomeController 클래스의 Index() 메쏘드를 다음과 같이 수정하겠습니다.
public ActionResult Index()
{
ViewData["Message"] = "Hello! ASP.NET MVC!!!";
return View();
}
소스 1 - /Controllers/HomeController.cs
컨트롤러는 ViewData 를 통해서 뷰에 데이터를 전달할 수 있습니다. 뷰에서는 인라인 코드로 ViewData에 접근할 수 있습니다. (자세한건 여기에서 'ViewData로 뷰에 전달하기'를 봐주세요) 수정한 내용은 F5 로 실행하여 확인할 수 있습니다.
그런데 주소를 보니 http://localhost:1589/로 되어있는데도 원하는 결과를 확인할 수 있습니다. ASP.NET MVC는 기존 웹폼에서처럼 직접적인 페이지 호출이 아닌 라우팅 룰에 의해 호출이 됩니다. ASP.NET MVC 애플리케이션이 처음 시작되면 Global.asax.cs 에 있는 Application_Start() 메쏘드가 호출되고 이는 라우트 테이블을 생성합니다.
소스 2 - Global.asax.cs
라우트 테이블은 들어오는 웹 요청을 3부분으로 나눕니다. 처음은 컨트롤러 이름과 매핑이되고, 두번째는 액션메쏘드와 매핑이 되고, 세번째는 그 메쏘드에 전달될 파라미터와 매핑이 됩니다. 예를들어, /Product/Detail/3 과 같이 요청이 들어오면 다음과 같이 나뉩니다.
Controller = ProductController
Acton = Detail
Id = 3
예제에서 주소가 http://localhost:1589/ 이렇게 되어도 라우트 테이블의 디폴트값인 HomeController의 Index 액션메쏘드를 호출하기 때문에 우리가 원하는 결과를 볼수 있었던 거죠^^
이제 인사는 나누었는데 처음 만남에 인사만 나누기는 섭섭하죠? ^^; 커피라도 한잔하며 얘기 나눠보
는게 좋겠죠? 흠.. 이번시간은 간단히 인사만 나누고 끝내려고 했는데요. 너무 금방 헤어지면 정말 아쉬울것 같아서 더 진행하는 것이니 간단하게 해보도록 하겠습니다. 아무쪼록 저의 허접함을 탓하지 마옵소서...(저 스스로 분발하도록 하겠습니다^^;)
Html.ActionLink() 메쏘드는 A 태그를 만듭니다. 링크를 MenuForm으로 하네요. 물론 실행해 보면 에러가 나겠죠. 메뉴컨트롤러와 해당 액션메쏘드가 없기 때문이죠. 그러면 컨트롤러를 생성해보도록 하겠습니다.
using HelloMVC.Models;
namespace HelloMVC.Controllers
{
public class MenuController : Controller
{
//
// GET: /Menu/
public ActionResult MenuForm()
{
List<Menu> MenuList = new List<Menu>();
MenuList.Add(new Menu { Id = 1, Name = "커피", Price = "4000" });
MenuList.Add(new Menu { Id = 2, Name = "레몬에이드", Price = "5000" });
return View(MenuList);
}
}
}
소스 4 - /Controllers/MenuController.cs
ViewResult로 MenuList 모델을 파라미터로 뷰페이지로 리턴합니다. 액션메쏘드에 아무데서나 마우스 오른쪽 버튼을 클릭하여 뷰페이지를 생성하도록 하겠습니다.
Add View를 클릭하면 다음과 같은 팝업이 뜹니다. 먼저 저희가 컨트롤러에서 메뉴를 추가한 리스트를 확인해보기 위해서 다음과 같이 세팅하도록 하겠습니다.
Create a stringly-typed view를 선택하고(뷰를 생성할때 모델과 강력한 결합을 이끌게 되면 직접적으로 모델의 애트리뷰트들을 액세스할수 있게 됩니다.), View data class 를 Menu클래스로 선택합니다. 마스터 페이지의 체크를 해제하도록 합니다. Add 버튼을 클릭하시면 MenuForm 페이지가 생성되는 것을 확인하실 수 있습니다. 바로 실행을 해보시면,
잘나오네요. 그러면 소스를 조금(?) 수정하도록 하겠습니다.
<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage<IEnumerable<HelloMVC.Models.Menu>>" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head id="Head1" runat="server">
<title>MenuForm</title>
</head>
<script type="text/javascript">
var menuList = new Array();
function Menu() {
this.id;
this.name;
this.price;
this.quantity = 0;
this.cPrice;
}
function addMenu(id, name, price) {
var menuNum = -1;
for (var k = 0; k < menuList.length; k++) {
if (id == menuList[k].id) {
menuNum = k;
break;
}
}
if (menuNum == -1) {
var mn = new Menu();
mn.id = id;
mn.name = name;
mn.price = price;
mn.quantity++;
mn.cPrice = price;
menuList.push(mn);
}
else {
menuList[k].quantity++;
menuList[k].cPrice = menuList[k].quantity * parseInt(menuList[k].price);
}
var str = "";
var totalPrice = 0;
for (var i = 0; i < menuList.length; i++) {
str += menuList[i].name + " " + menuList[i].quantity + "잔 " + menuList[i].cPrice + "<br />";
totalPrice += parseInt(menuList[i].cPrice);
}
document.getElementById("divMenuList").innerHTML =
ASP.NET 4 Web Forms에서 작은 추가가 이었는데, 그것은 Page 클래스의 두 속성 MetaKeywords 와MetaDescription 입니다. 이 두 속성들은 당신의 페이지 안에 부합하는 메타 태그를 다시 표현했습니다. 다음 예를 보세요.
<head id="Head1" runat="server">
<title>Untitled Page</title>
<meta name="keywords" content="These, are, my, keywords" />
<meta name="description" content="This is the description of my page" />
</head>
이 두 속성들은 페이지의 Title 속성이 하던 것과 같은 방법으로 작동합니다. 그것들은 이 두 가지 규칙을 따릅니다.
속성 네임을 대응하는 head 요소 안에 meta 태그들이 없다면(즉, Page.MetaKeywords 위하여 name="keywords" 이고 Page.MetaDescription 을 위하여 name="description" 이며, 이 속성들이 설정되지 않은 것을 의미합니다), meta 태그들은 그것이 랜더링 될 때, 그페이지에 추가 될 것입니다.
이 이름들과 함께 이미 meta 태그들이 있다면, 이 속성들은 존재하는 태그들의 내용을 위한 get과 set 매소드로 활동합니다.
당신은 런타임에서 이 속성들을 설정할 수 있습니다. 그것은 당신이 DB 혹은 다른 소스로부터 내용을 얻게하며, 당신이 특정 페이지들을 위한 것을 설명하기 위하여 동적으로 그 태그들을 설정하게 합니다. 당신은 또한 웹폼 페이지 마크업 맨 위에 @ Page 지시어에서 Keywords 와 Description 속성을 설정 할 수 있습니다. 다음 예를 보세요.
<%@ Page Language="C#" AutoEventWireup="true"
CodeFile="Default.aspx.cs"
Inherits="_Default"
Keywords="These, are, my, keywords"
Description="This is a description" %>
이것은 페이지 내에서 이미 선언된 것이 있다면 meta 내용을 오버라이드 할 것입니다. 설명 meta 태그의 내용이 구글에서 향상된 검색 목록화 미리보기를 위하여 사용 됩니다. (부연 설명으로 구글 웹마스터 센트럴 블로그에서 Improve snippets with a meta description makeover 를 보세요) 구글과 윈도우 라이브 서치는 어떤 것을 위해서 키워드들의 내용을 사용하지 않습니다. 그러나 다른 검색 엔진은 가능 할 것입니다. 덧붙여 검색 엔진 가이드 웹사이트의 Meta Keywords Advice 를 보세요. 이 새로운 속성들은 간단한 특징입니다. 그러나 그것들은 당신이 이것들을 수동으로 추가할 필요가 있을 때 혹은 meta 태그를 만들기 위하여 당신 자신의 코드를 쓸 때 부담을 덜어 줄 것입니다.
기본적으로 뷰 스테이트는 페이지에서 작동합니다. 결과적으로 페이지상의 각 컨트롤은 그것이 어플리케이션을 위해 필요하지 않다면 잠재적으로 뷰 스테이트를 저장합니다. 뷰 스테이트의 데이타는 페이지의 HTML 안에 포함되고, 클라이언트에게 페이지를 보내는데 걸리리는 시간을 증가시키고, 그것을 포스트 백합니다. 필요 이상으로 뷰 스테이트를 저장하는 것은 중요한 처리능력 감소의 원인이 될 수 있습니다. 초기 버전의 ASP.NET에서, 개발자들은 페이지 사이즈를 줄이기 위하여 개별적인 컨트롤들을 위한 뷰스테이트를 자제 할 수 있었습니다. 그러나 개별적 컨트롤들을 위하여 아주 명시적으로 해야했습니다. ASP.NET 4에서, 웹 서버 컨트롤들은 ViewStateMode 속성을 포함하였습니다. 그것은 당신이 기본적으로 뷰 스테이트를 자제하게 하였습니다. 그리고 페이지에서 그것을 필요로 하는 컨트롤들을 위해서만 그것을 사용하게 하였습니다. ViewStateMode 속성은 3가지 값을 취합니다: Enabled, Disabled, 그리고 Inherit. Enabled 그 컨트롤과 상속받거나 혹은 설정되지 않은 자식 컨트롤을 위하여 뷰 스테이트를 가능하게 하였고습니다. Disabled 은 뷰 스테이트를 사용하지 못하게 합니다. 그리고, Inherit 는 그 컨트롤이 부모 컨트롤로부터 설정하고 있는 ViewStateMode 를 사용하는 것을 구체화 시킵니다. 다음의 간단한 예는 ViewStateMode 속성이 어떻게 동작하는지 보여줍니다. 다음 페이지 안에 컨트롤들을 위한 마크업은 ViewStateMode 값을 포함합니다:
당신이 보신 것처럼, 코드는 PlaceHolder1 컨트롤을 위한 뷰스테이트를 디스에이블 합니다. 자식 label1 컨트롤은 이 속성 값을 상속합니다.(Inherit 는 컨트롤의 ViewStateMode 를 위한 기본 값입니다.) 그리고 결과적으로 뷰스테이트를 저장하지 않습니다. PlaceHolder2 컨트롤에서 ViewStateMode 는 Enabled 로 설정되고, 그 결과 label2 는 이 속성을 상속합니다. 그리고 뷰 스테이트를 저장합니다. 페이지가 처음 로드 될 때, 두 Label 컨트롤의 Text 속성은 문자열 "[DynamicValue]"로 설정됩니다. 이 설정들의 효과는 페이지가 처음 로드 할 때, 다음의 출력을 브라우저상에 보여줍니다.
Disabled: [DynamicValue]
Enabled: [DynamicValue]
그러나 포스트백 후에 다음의 출력이 보여집니다:
Disabled: [DeclaredValue]
Enabled: [DynamicValue]
아마도 당신이 예상하기로는, label1 (label1 의 ViewStateMode 값은 Disabled 설정 됨)은 코드안에 설정된 값을 보존하지 않았습니다. 그러나, label2 (label2 의 ViewStateMode 값은 Enabled 설정 됨)는 그것의 상태를 보존합니다. 당신은 또한 @ Page 지시어에서의 ViewStateMode 를 설정 할 수 있습니다. 다음 예를 보세요:
Page 클래스는 단지 다른 컨트롤이다; 그것은 페이지 상에서 다른 모든 컨트롤들의 부모 컨트롤로서 동작합니다. ViewStateMode 의 디폴트 값은 Page 객체를 위하여 Enabled 입니다. 왜냐하면 컨트롤들이 상속하기위하여 디폴트로 하기 때문에, 컨트롤들은 당신이 페이지 혹은 컨트롤 단계에서 ViewStateMode 를 설정하지 않더라도 Enabled 속성 값을 상속할 것입니다. ViewStateMode 속성 값은 EnableViewState 속성이 true로 설정되야만 뷰 스테이트가 유지될지 아닐지를 결정합니다. EnableViewState 속성이 false 로 설정이 되면, 뷰 스테이트는 ViewStateMode 가 Enabled 로 설정되어도 유지 되지 않을 것입니다. 이 특징을 살린 좋은 사례는 마스터 페이지안에 ContentPlaceHolder 컨트롤과 함께 사용하는 것입니다. 당신은 마스터 페이지를 위하여 ViewStateMode 를 ViewStateMode 로 설정 할 수 있습니다. 그런 다음에 ContentPlaceHolder 컨트롤을 위하여 그것을 개별적으로 인에이블 할 수 있습니다. 그ContentPlaceHolder 는 뷰스테이트가 필요한 컨트롤들을 차례로 포함합니다.
ASP.NET은 브라우저의 능력을 결정하는데, 사용자는 browser capabilities 라고 불리는 특징을 사용하는 것에 의하여 당신의 사아트를 탐색하는데 그것을 사용하고 있습니다. 브라우저 지원은 (Request.Browser 속성에 의하여 보여지는) HttpBrowserCapabilities 객체에 의하여 대표됩니다. 예를 들어, 당신은 현재 브라우저의 타입과 버전이 특별한 버전의 자바스크립트를 지원하는지를 알아내기 위하여 HttpBrowserCapabilities 객체를 사용할 수 있습니다. 혹은, 당신은 요청이 모바일 장치로부터 비롯된 것인지를 알아내기 위하여 HttpBrowserCapabilities 객체를 사용 할 수 있습니다. HttpBrowserCapabilities 객체는 한 세트의 브라우저 정의 파일들에 의해서 작동됩니다. 이 파일들은 특정 브라우저들의 지원에 대한 정보를 포함합니다. ASP.NET 4에서 이 브라우저 정의 파일들은 최근 소개된 브라우저들과 구글 크롬, Research in Motion 블랙베리 스파트폰들과 애플 아이폰 같은 장치들에 대한 정보를 포함하기 위하여 업데이트 됩니다.
다음의 목록은 새로운 브라우저 정의 파일들입니다.
blackberry.browser
chrome.browser
Default.browser
firefox.browser
gateway.browser
generic.browser
ie.browser
iemobile.browser
iphone.browser
opera.browser
safari.browser
Using Browser Capabilities Providers
ASP.NET 3.5 서비스팩1에서, 당신은 다음의 방법들 중에서 지원을 정의 할 수 있습니다.
machine 레벨에서, 당신은 다음의 폴더 안에서 .browser XML 파일들을 만들거나 업데이트 할 수 있습니다.
당신이 브라우저 지원을 정의한 후에, 당신은 Visual Studio Command Prompt로 부터 다음의 명령어를 실행합니다. 그것은 브라우저 지원 어셈블리를 재빌드하고 GAC(Global Assembly Cache)에 그것을 덧붙이기 위해서 입니다.
aspnet_regbrowsers.exe -I c
개별적인 어플리케이션을 위하여, 당신은 어플리케이션의 Browsers 폴더 안에서 .browser 파일들을 만들 수 있습니다.
이 접근들은 당신이 XML 파일들을 바꾸는데 필요하고, machine 레빌의 변화를 위해서 당신은 aspnet_regbrowsers.exe 프로세스를 돌린 후에, 어플리테이션을 재시작 해야 합니다. ASP.NET 4 는 브라우저 지원 공급자(rowser capabilities providers) 으로 관련된 특징을 포함합니다. 그 이름이 제안했을 때, 이것은 당신이 공급자를 빌드하게 합니다. 그 공급자는 순차적으로 당신이 브라우저 지원을 알아내기 위하여 당신의 코드를 사용하게 합니다. 실제로는, 개발자들이 종종 커스텀 브라우저 지원을 정의하지 않습니다. 브라우저 파일들은 업데이트하기 어려운데, 그 이유는 그것들을 업데이트를 위한 프로세스가 아주 복잡하기 때문입니다. 그리고 .browser 파일들을 위한 XML 문법은 사용하고 정의하기에 복잡할 것입니다.
아주 초기에 이 프로세스를 만드는 것은 공통 브라우저 정의 문법이 혹은 최근의 브라우저 정의를 포함하는 데이터베이스 혹은 심지어 그러한 데이터베이스를 위한 웹서비스라고 할지라도 가능하였습니다. 새로운 브라우저 지원 공급자의 특징은 제 3의 개발자들을 위해서 가능하고 실제적인 이 시나리오들을 만듭니다. 새로운 ASP.NET 4 브라우저 지원 공급자 특징을 사용하시 위해서 두 가지의 주된 접근법이 있습니다: ASP.NET 4 브라우저 지원 정의 기능을 확장하기 위해서, 혹은 전체적으로 그것을 대체하는 것. 다음 절은 최초로 그 기능을 대체하는 법과 그 다음에 그것을 확장하는 법을 설명합니다.
Replacing the ASP.NET Browser Capabilities Functionality
ASP.NET 브라우저 지원 정의 기능을 대체하기 위하여, 이 단계를 따라주세요:
1. HttpCapabilitiesProvider 로 부터 상속한 공급자 클래스를 만듭니다. 그리고 다음의 예처럼
GetBrowserCapabilities 매소드를 오버라이드하는 공급자 클래스를 만듭니다.
public class CustomProvider : HttpCapabilitiesProvider
{
public override HttpBrowserCapabilities
GetBrowserCapabilities(HttpRequest request)
{
HttpBrowserCapabilities browserCaps = new HttpBrowserCapabilities();
Hashtable values = new Hashtable(180, StringComparer.OrdinalIgnoreCase);
values[String.Empty] = request.UserAgent;
values["browser"] = "MyCustomBrowser";
browserCaps.Capabilities = values;
return browserCaps;
}
}
이 예 안의 코드는 새로운 HttpBrowserCapabilities 객체를 만듭니다. 그것은 브라우저를 명명하는 지원을 상세화하고, MyCustomBrowser에 지원을 설정합니다.
2.Register the provider with the application. 어플리케이션과 함께 공급자를 등록합니다.
어플리케이션과 함께 공급자를 사용하기 위하여, 당신은 Web.config 혹은 Machine.config 파일 안의 browserCaps 섹션에 provider 특성을 덧붙여야 합니다. (특정 모바일 장치를 위한 폴더 처럼, 당신도 어플리케이션 안의 특별한 디렉토리들을 위하여 location 요소 안의 공급자 속성을 정의 할 수 있습니다. ) 다음의 예는 구성 파일안의 provider 속성을 설정하는 법을 보여줍니다.
이 코드는 Global.asax 파일의 Application_Start 이벤트 안에서 동작합니다. 캐쉬가 결정된 HttpCapabilitiesBase 객체를 위한 유효한 상태로 남기위해서, BrowserCapabilitiesProvider 클래스에서 변화는 어플리케이션 실행 중 코드 전에 일어나야합니다.
SQL Azure에 대해 어느 정도 살펴보았으며 간단하게 현재 운영하고 있는 SQL Server와 비교를 나열해보려고 합니다. 현재 CTP를 살펴본 내용으로 저와 생각이 상이할 수 있습니다.
그리고 실제 운영한다면 많이 차이점을 구체적으로 느낄 것 같습니다.
먼저 SQL Azure의 이점을 아래에서 살펴봅니다.
1.관리적 요소와 확장성
패치 등등 많은 관리적 오버헤드 없이 손쉽게 엔터프라이즈의 데이터 서비스 응용프로그램 기능을 제공할 수 있습니다. 그리고 저장소 증가로 인한 비용은 현재 사용하고 있는 저장소에 대한 비용만을 지불하면 됩니다. 초기 비용에 대한 감소가 매력적으로도 보입니다. 데이터 센터인데 관리적으로 별 신경 안써도 된다는 것이라고 생각됩니다.
2.고 가용성
SQL Azure 는 물리적으로 여러 복사본이 생성되어 비즈니스 연속성과 고 가용성을 제공해주고 있습니다. 하드웨어 고장시 자동 Failover를 제공합니다. 이 또한 관리적 요소와 초기 비용의 감소를 제공합니다.
3.개발 및 관계형 데이터 모델
SQL Azure는 TDS를 통해 Client와 Server 사이 통신을 지원함으로 익숙한 개발 모델로 접근할 수 있습니다. Visual Studio 2010을 통해 ADO.NET으로 접근한다면 거의 동일한 코드를 사용하게 됩니다. 개발 모델에서는 별 차이를 느끼지 못합니다. 그리고 SSIS를 통해서도 SQL Azure를 접근할 수 있습니다.
SQL Azure를 개체 탐색기에 연결하면 관리하고 있는 여러 인스턴스 중의 하나로 보입니다. 또한 로컬의 데이터베이스와 유사하게 테이블, 뷰, 저장 프로시저, 인덱스 등을 생성할 수 있습니다. 하지만 조금 차이점이 있으며 아래에서 T-SQL 의 지원 내용을 알아봅니다.
안녕하세요. 이번에 새롭게 팀원이된 박세식이라고 합니다. 많이 부족해서 컴터앞에 앉아 이렇게 자판을 두드리고 있는 시간에도 떨림이 멈추질 않네요-_-; 앞으로 잘 부탁드리겠습니다.(따스~한 피드백 아시죠^^;) 자~ 그럼. ASP.NET MVC에 대해 알아보도록 하겠습니다.
첫번째 시간으로 ASP.NET MVC vs ASP.NET WEB FORM 에 대해 글을 써보도록 하겠습니다. 제 포스트는 ASP.NET MVC에 관한 글입니다.^^; 그래서 이 둘의 대결구도라기 보다는 웸폼의 문제점을 짚어보고 MVC에 좋은 점에 대해서 글을 써 나가려고 합니다.
ASP.NET WEB FORM의 문제점?
ASP.NET WEB FORM은 ASP.NET 개발의 전통적인 스타일이고, 큰 스케일의 웹사이트를 좀더 간단하게 만들게 해주는 기술입니다. 웹폼은 드래그 앤 드랍으로 컨트롤들을 ASP.NET 페이지에 추가하고 그것들에 맞는 코드를 작성합니다. 이러한 개발방식이 개발자들의 마음을 끄는거죠. 그!러!나! 웹폼은,
● 관계가 분리되어 있지 않습니다. UI와 코드가 섞여있죠--; ● 자동적으로 테스트하는 것이 쉽지 않습니다. 런타임 시작없이 테스트하기가 어렵죠. 이는 실행환경을 쭉~ 돌면서 테스트할 수 밖에 없다는 겁니다-_-; ● 상태정보를 저장하려면 각 서버페이지의 상태를 뷰스테이트라고 하는 히든 필드값으로 클라이언트 페이지에 저장합니다.
하지만, 웹폼 개발에서의 특징인 뷰스테이트와 포스트백은 축복이자 파멸의 원인이됩니다. 뷰스테이트는 클라이언트와 서버간의 오고가는 데이터들의 상태를 히든 필드로 구성하고 있는 메커니즘으로, 이것의 크기는 무지막지하게 커질 수 있습니다. 매번 호출시 이 거대한 데이터가송수신된다니 끔찍스럽죠-_-; 특히 페이지에 데이터그리드나 그리드뷰와 같은 서버컨트롤이 포함되어있다면 한페이지 한페이지 넘길때마다 응답지연의 원인이 되어 사용자들을 기다림에 지치게 만드는거죠 OTL;; 또한 포스트백은 매번 액션에 의한 트리거로서 발생이됩니다. 그 거대한 데이터(뷰스테이트)를 어떤 액션만 취하게 되면 다시 그리게 되는거죠. 이 뷰스테이트에 대해 좀더 알아보죠.
뷰스테이트(View State)란?
뷰스테이트는 포스트백시 웸폼의 상태의 변화를 유지시켜주는 기술입니다. 일반적으로 __VIEWSTATE라는 이름의 히든 필드로 웹페이지에 위치합니다. 이 히든값은 수십 킬로바이트씩 쉽게 커질 수 있습니다. 이 뷰스테이트는 사용자가 웹 페이지를 포스트백 할 때 천천히 불려지고(다운로드), 그 히든 값의 내용을 웹 요청시에 포스트해서 요청 시간을 길어지게 합니다. ASP.NET 웹 페이지의 요청이 올 때 정확하게 무슨 일이 일어나는지를 알려면 ASP.NET 페이지의 생명주기(Life Cycle)을 알아봐야 하는데요. 잠깐 간단하게만 알아보도록 하죠^^;(어째~ 이야기가 점점 옆으로 새네요.. 언제 제자리로 돌아올지는 생각하지 말아주세요-_-;)
Asp.Net Page Life Cycle
매번 ASP.NET 웹 페이지에 의해 서버에 요청이 오면 첫째로 웹 서버는 ASP.NET 엔진으로 요청을 넘깁니다. ASP.NET 엔진은 웹 페이지의 올바른 파일 접근을 확인하는 여러 단계로 구성된 파이프라인을 통해서 사용자의 세션 정보를 얻습니다. 파이프라인의 끝에서는 요청된 웹 페이지에 상응하는 클래스를 인스턴스화하고 ProcessRequest() 메쏘드를 호출합니다. ASP.NET 페이지의 생명주기는 ProcessRequest() 를 통해서 시작됩니다. 이 메쏘드는 페이지의 컨트롤 단계를 준비합니다. 그 다음으로, 페이지와 서버는 ASP.NET 웹 페이지에 필요한 여러 단계를 하나씩 단계별로 밟게 됩니다. 이 단계들에는 뷰스테이트를 관리하고, 포스트백 이벤트를 처리하고, HTML 페이지를 렌더링하는 것들이 포함되어 있습니다.
다시 뷰스테이트로 돌아와서 정리하자면, 세상에 공짜는 없습니다.(비용이 든다는거죠) 여기 뷰스테이트도 예외일 수는 없습니다^^; ASP.NET 페이지가 요청될 때마다 뷰스테이트는 두가지 성능에 관련되는 일을 합니다. 첫째는, 모든 페이지를 방문할 때 뷰스테이트는 해당 컨트롤 계층의 모든 컨트롤의 뷰스테이트를 모아서 베이스 64 인코딩으로 시리얼라이즈합니다. 여기서 생성된 스트링이 __VIEWSTATE에 값인거죠^^
반대로, 포스트백시에는 뷰스테이트를 읽엇 저장된 뷰스테이트 데이터로 디시리얼라이즈하고 컨트롤 계층구조에 있는 적절한 컨트롤러로 업데이트합니다. 두번째로, 뷰스테이트는 클라이언트가 다운로드 받아야할 웹페이지의 크기를 증가시킵니다. 원래 보여질 페이지의 데이터와는 또다른 데이터인거죠. 뷰스테이트 크기가 큰 페이지는 이 뷰스테이트의 크기가 수십 킬로바이트가 됩니다. 이것을 다운받기 위해 또 수 초나 수 분의 시간을 할애해야합니다.(이게~ 뭔가요-_-;) 또, 포스트백시에도 뷰스테이트를 웹 서버로 보내야하고, 그것 때문에 포스트백 요청시간이 증가하는 거죠.
● 뷰(View) 는 애플리케이션의 UI를 담당하고, 이는 단지 컨트롤러에 의해 애플리케이션의 데이터로 채워질 HTML 템플릿에 지나지 않습니다. ● 모델(Model) 은 UI를 렌더링하는 뷰가 사용할 애플리케이션의 객체, 즉 애플리케이션의 데이터의 비즈니스 로직을 구현합니다. ● 컨트롤러(Controller) 는 사용자 입력과 상호작용하는 응답을 핸들링합니다. 웹 요청은 컨트롤러에 의해 핸들링되고, 요청된 URL의 표현될 뷰와 적절한 데이터(모델 객체)를 결정합니다.
ASP.NET MVC의 요청 흐름도
ASP.NET MVC 애플리케이션은 웹폼과 같이 주소창에 입력된 URL이 해당서버의 디스크에 있는 페이지(파일)을 찾는것이 아닌 컨트롤러를 통한 뷰를 호출하게 됩니다. URL은 컨트롤로와 매핑이 되고 컨트롤러는 뷰를 리턴해주는 식이죠. 다음의 그림을 보시면
처음 사용자 요청(URL)이 들어오면 Routing Rule 에 의해 컨트롤러를 매핑시킵니다. Routing Rule 은 ASP.NET MVC 프로젝트를 생성하면 Global.asax에 정의되어 있는데요. 제 블로그에 컨트롤러를 설명하면서 Global.asax에 대해 간략하게 설명한 부분이 있는데요 참고하시기 바랍니다. 여기서도 간단히 설명드리자면, 주소는 {controller}/{action}/{id} 이런식으로 들어오게됩니다. 특정 컨트롤러의 특정 액션메쏘드의 파라미터로 id를 넘겨준다는 룰이죠. (액션메쏘드는 컨트롤러 클래스에서 public으로 제공되는 메쏘드를 가리킵니다.)
다시, 컨트롤러는 뷰에 넘겨줄 데이터를 만들 모델을 선택합니다. 선택된 모델객체는 뷰에 넘겨줄 데이터(ViewData)를 만들고, 컨트롤러가 이를 뷰에 넘겨줍니다. 마지막으로 뷰는 HTML로 렌더링해서 사용자에게 보여줌으로 하나의 흐름이 흘러가는 거죠^^;
그래서 ASP.NET MVC의 장점은?
● 모델, 뷰, 컨트롤러로 명확하게 관계과 분리되어 있어 복잡한 애플리케이션 로직을 관리하기 쉽게 해줍니다. 이로 인해 각 개발자는 MVC 패턴의 분리된 컴포넌트를 각자 개발할 수 있습니다. 페이지 단위로 되어 있는 웸폼은 비하인드 코드에서 로직을 담당하게 되는데요. 다른 두개의 페이지에서 비슷한 작업을 하게 된다해도 하나의 작업으로 사용하기가 어렵다는 거죠^^; 특정 페이지의 이벤트가 그 페이지의 비하인드 코드를 호출하기 때문에 같은 작업을 해도 저처럼 잘 모르는 사람들은 저희에게 무한한 능력(?)을 심어주는 카피 앤 페이스트 작업을 거쳐야한다는 겁니다.
● 유닛테스팅을 쉽게해줍니다. 이 유닛테스트도 M,V,C 가 각각 깔끔하게 분리되어 있어주기 때문에 가능한거죠^^; 추후에 유닛테스트가 과연 얼마나 쉬운지 알아보는 시간을 갖도록 하겠습니다.
● MVC 모델은 뷰스테이트와 포스트백을 사용하지 않습니다. 그래서, MVC는 일반적으로 웹폼에 비해 페이지 사이즈가 작습니다. 폼의 히든 필드인 뷰스테이트 데이터와 같은 불필요한 데이터가 없기 때문이죠.
● 웸폼 모델에서의 URL이 서버의 존재하는 파일을 직접 요청하는 것 대신에 REST 방식의 URL을 사용하여 URL을 간단하게 해주고, 기억하기 쉽게 해주고, SEO의 도움을 줍니다.
SEO(Search Engine Optimization) 는 검색엔진의 결과로 보여질 랭크의 순위를 높이는 작업을 말합니다. 상위 랭크의 검색결과로 나타내어지면 사용자가 아무래도 계속 그것만 보게되니 좋겠죠^^; 그래서 URL 또한 사용자가 보기 쉬운 걸로 나타내면 좋다는거죠. 예를들어, /Product/Edit/4 이런 URL 이라면 4번째 상품을 수정하겠다는 거군. 이렇게 명시적으로 알수 있다는 겁니다. 예가 좀 부적합한가요^^;
● jQuery나 ExtJS와 같은 클라이언트단 자바스크립트 프레임워크와 쉽게 통합할 수 있습니다.
마무리요
사실, 웸폼과 MVC를 비교해서 꼭 이것이 더 좋으니까 이것만 사용해야지가 아닙니다. 각 프로젝트의 특성에 맞게 선택하는 거죠. (다시한번 말씀드리지만 이 포스트는 ASP.NET MVC에 관한 글입니다--;) 성능을 따지지 않고 빠른 개발을 원한다면 웹폼을 선택하는 것이 좋을 것 같고, 유닛테스팅과 성능에 중점을 두겠다 싶으면 MVC쪽을 선택해봄이 좋겠다는 거죠. 다음 포스트에는 예제를 통해서 ASP.NET MVC와 인사를 나눠보는 시간을 갖도록 하겠습니다^^
SQL Azure에 데이터베이스와 데이터가 있으므로 응용 프로그램에서 액세스 해보도록 하겠습니다.
응용 프로그램이 Cloud 환경이 아닌 모습이라면 Far Application 이라고 말하며
SQL Azure 와 응용 프로그램이 같은 Cloud 환경이라면 Near Application 이라고 말합니다.
Visual Studio 2010으로 ASP.NET Web Role Application을 생성하여 Far, Near 응용 프로그램을 처리해보도록 하겠습니다.
먼저 등록된 SQL Azure의 데이터 쿼리 결과입니다.
위의 데이터를 Cloud Service의 ASP.NET Web Role 에서 액세스하고 Cloud로 게시해봅니다.
먼저 Visual Studio 2010에서 Cloud Service > Windows Cloud Azure Service 에서 ASP.NET Web Role 프로젝트를 생성합니다.
Web Role의 Default.aspx 에 대한 페이지는 많은 내용 없이 SQL Azure를 연결하여 Category 데이터와 SubCategory 데이터를 표시해주는 것으로 구성해보겠습니다.
Default.aspx의 화면 디자인은 DropDownList와 GridView 컨트롤을 배치합니다.
아래처럼 간단한 ADO.NET 프로그래밍을 통해 저장 프로시저를 호출하여 DropDownList1 과 GridView1에 데이터를 바인딩 합니다. 연결 문자열은 Web.Config에 connectionStrings 섹션에 위치시킵니다. 로컬 데이터베이스에서 테스트하고 SQL Azure 의 연결 문자열로 변경하도록 합니다.
로컬 데이터베이스에서 테스트하고 SQL Azure로 결과를 테스트하면 아래와 같은 결과를 볼 수 있으며 아래 형태가 Cloud와 코드가 멀리 있는 Far Application 형태가 됩니다. 웹뿐만 아니라 Cloud의 여러 서비스가 있다면 Windows Form에서도 액세스 가능하다는 것을 알 수 있습니다.
이제 Near Application으로 Windows Azure로 게시해봅니다. 솔루션 탐색기에서 게시를 선택해서 Windows Azure 사이트의 서비스에 cspkg 확장자 파일과 cscfg 확장자 파일을 업로드하고 게시합니다.
Production에도 게시를 하여 Azure URL로 접속하면 아래와 같은 결과를 얻을 수 있습니다.
물론 SQL Azure에 대한 방화벽 설정을 해주어야 합니다.~
요약하면 데이터베이스와 데이터가 게시된 SQL Azure를 이용하는 Cloud Application을 생성해보았습니다.
Microsoft Ajax 라이브러리는 오직 클라이언트 자바스크립트 라이브러리입니다. 그것은 인터넷 익스 플로러, 구글 크롬, 애플 사파리, 그리고 모질라 파이어폭스를 포함한 현대의 모든 브라우저에 호환성을 갖고 있습니다.
당신은 웹브라우저에서 완벽히 작동하는 높은 응답성과 쌍방향의 DB로 이루어진 웹 어플리케이션을 구축하는데 Microsoft Ajax 라이브러리가 도움을 줄 수 있습니다. Microsoft Ajax 라이브러리는 오직 클라이언트 자바스크립트 라이브러리이기 때문에, 당신은 ASP.NET 웹 폼과 ASP.NET MVC 어플리케이션과 함께 그 라이브러리를 사용할 수 있습니다. 당신은 또한 단지 HTML로 이루어진 Ajax 페이지들을 만들 수 있습니다. Microsoft Ajax 라이브러리는 오픈소스로서 ASP.NET 4과 독립적으로 배포되었으며, 완벽히 제품을 지원하게 됩니다. http://www.asp.net/ajax/ 당신은 다음의 웹사이트 주소로부터 Microsoft Ajax 라이브러리의 최신 버전을 다운로드 할 수 있습니다.
Note: ASP.NET 4는 이 섹션에서 설명된 특징을 지원한지 않는 Microsoft Ajax 초기 버전을 포함합니다. 반드시 ASP.NET 웹사이트로 부터 최신 버전을 다운로드 해주세요.
Sys.require 매소드는 그 다음에 스크립트 로더를 사용합니다. 당신은 Sys.require 매소드에 컴포넌트의 이름(혹은 컴포넌트의 배열)과 콜백 매소드를 제공합니다. 컴포넌트에 의하여 요구된 모든 스크립트들이 로드되었을 때, 콜백 매서드는 불러오게 됩니다. 예를 들어, 이전의 코드는 다음의 스크립트들을 로드합니다. 그것은 워터마크 칸트롤에 모두 필요합니다:
MicrosoftAjaxComponentModel.js
MicrosoftAjaxCore.js
MicrosoftAjaxGlobalization.js
ACTCommon.js
ACTExtenderBase.js
ACTWatermark.js
성능을 향상시키기 위하여, 스크립트 로더들은 이 스크립트들 모두 동시에 로드랍니다. 그리고 올바른 순서로 그 스크립트를 실행합니다. 그 스크립트 로더는 아주 영리해서 단지 한번 요청된 스크립트를 로드합니다. 당신은 페이지에 스크립트로더를 추가할 수 있는데, 그것은 Start.js파일을 참조하는 script 태그를 덧붙이는 것입니다. Start.js 파일은 당신의 로컬 서버에 있을수 있고, 혹은 당신은 다음의 스크립트 태그를 사용하여 Microsoft Ajax Content Delivery Network 상에서 Start.js 파일을 참조할 수 있습니다.
당신이 Start.js에서 참조한 후에, 당신은 Sys.requires를 사용하는 것에 의하여 다른 필요한 자바스크립트 파일을 로드할 수 있습니다. Microsoft Ajax Content Delivery Network에 대하여 더 많이 배우기 위해서, ASP.NET 웹사이트 상의 Microsoft Ajax CDN를 보세요.
Microsoft Ajax 라이브러리는 웹브라우저 상에서 완전히 동작하는 DB로 이루어진 웹 어플리케이션을 빌드 가능하게합니다. 클라이언트가 데이터에 접근 가능하게 하는 Microsoft Ajax의 3가지 특징이 있습니다.
Client data controls
Client templates
Client data context
클라이언트 DataView 컨트롤은 하나의 혹은 다수의 데이터베이스 레코드를 보여 줄 수 있게 합니다. 당신은 클라이언트 템플릿을 만드는 것으로 DataView 컨트롤을 통하여 데이터 베이스 레코드들을 보여 줍니니다. 예를 들어, 당신은 모든 데이터베이스를 보여주는 다음의 코드처럼 코드를 사용할 수있습니다. 그 데이터베이스 레코드들은 MovieService라고 이름 붙여진 WCF 서비스로부터 찾게 될 수 있습니다.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head>
<title>Movies</title>
<link href="Site.css" rel="stylesheet" type="text/css" />
예제 속의 자바스크립트 코드는 모든 스크립트를 로드하기 위하여 클라이언트-스크립트를 사용합니다. 그 스크립트들은 DataView 컨트롤과 MovieService WCF 서비스로 부터 데이터를 찾기 위한 DataView 컨트롤에 의하여 사용된 DataContext 컨트롤의해 필요했습니다. 다음 DataView 컨트롤은 생성되고, ID moviesView를 갖는 HTML UL요에 덧붙여졌습니다. 클라이언트 템플릿은 페이지의 바디안에 포함되고, 다음과 같습니다:
DataView 컨트롤은 클라이언트 템플릿과 함께 WCF 서비스로부터 찾아진 각 데이터베이스 레코드를 구성합니다. {{Title}} 플레이스홀더는 Movie 값을 보여줍니다. Title 속성과 {{Director}} 플레이스홀더는 Movie.Director 속성 값을 보여줍니다. 당신이 위 문서를 필요할 때, 다음의 페이지는 웹브라우저에서 렌더링 됩니다.
Microsoft Ajax 라이브러리는 클라이언트 DataContext 클래스를 포함하는데, 그것은 SQL DataContext 혹은 객체 프레임워크 ObjectContext 클래스에서 서버 쪽의 LINQ와 동등한 개념의 클라이언트 사이드입니다.
DataContext 클래스는 다음의 특징을 갖고 있습니다:
DB의 데이터에 접근하여 읽고, 쓰는 것을 지원합니다.
아이덴티티 관리와 변화 추적을 지원합니다.
복잡한 링크들을 관리하기 위한 지원과 다중의 객체 집단 혹은 테이블들로 부터 객체들 사이에 조합을 지원합니다.
Microsoft Ajax 라이브러리는 일반적인 DataContext 클래스를 포함합니다. 그리고 당신이 ASP.NET 혹은 WCF Web 서비스가 상호작용하기 윈할 때 사용할 수 있습니다. Microsoft Ajax 라이브러리는 또한 AdoNetDataContext 클래스를 포함하며 당신이 쉽게 ADO.NET Data Services 함께 상호작용 할 수 있도록 설계되었습니다. 당신은 DB의 데이터를 찾고 업데이트 할 대 모두 DataContext 혹은 AdoNetDataContext 클래스를 사용 할 수 있습니다.
jQuery 라이브러리는 아주 인기있는 오픈소스 자바스크립트 라이브러리 이며, ASP.NET 웹폼과 ASP.NET MVC 안에 모두 포함되어 있습니다. Microsoft Ajax 라이브러리는 jQuery 개발자들에게 마음에 들도록 설계되었습니다. 당신은 jQuery 플러그인과 Microsoft Ajax 클라이언트 컨트롤들을 같은 Ajax 어플리케이션에서 문제없이 함께 사용 할 수 있습니다.
예를 들어, 다음 페이지에서 Microsoft Ajax 워터파크 컨트롤은 당신이 jQuery 플러그인으로 만들려고 사용했을 때 처럼 같은 문법을 사용하면서 창조 되었습니다.
<!DOTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>jQuery Watermark</title>
<link href="Site.css" rel="stylesheet" type="text/css" />
jQuery $(".required") 섹터는 요구한 CSS 클래스를 가진 페이지로 부터 모든 요소를 찾기위하여 사용 되었습니다. 워터마크는 매칭하는 모든 요소에 덧붙여 졌습니다. Microsoft Ajax 라이브러리가 jQuery 체이닝을 지원하는 것을 알려줍니다. 워터마크가 jQuery 섹터에 의하여 반환된 요소들에 적용된 후에, 매치되는 모든 요소의 배경색과 두드러진색이 바뀌어졌습니다. jQuery 섹터에 의하여 반환된 같은 wrapped set에 반하여, 다중의 연산들이 수행 되었습니다.
Web.config 파일은 웹 어플리케이션을 위한 구성정보를 포함하고 있는데, AJAX, 라우팅, IIS 7과 함께 인티그레이션 같은 새로운 특징들이 추가되었기 때문에 닷넷 프레임워크의 과거 일부 릴리즈들 보다 꽤 늘어났습니다. 이것은 비쥬얼 스튜디오 같은 툴 없이 새로운 웹어플리케이션을 구성하거나 시작하는데 더 어렵게 만들었습니다. 닷넷 프레임워크 4에서 주요한 구성정보들은 machine.config 파일로 이동하게 되었고, 어플리케이션들은 지금 이 설정들을 상속합니다. 이것은 빈 공간으로 남겨 두던지 아니면 단지 어플리케이션이 목표로하는 프레임워크의 버전이 무엇인지를 비주얼 스튜디오를 위하여 명시하는 다음의 줄들을 ASP.NET 4 어플리케이션들 안의 Web.config에 남겨주기만 하면 됩니다.
ASP.NET 1.0이 배포 되었을때 부터, 아웃풋 캐싱은 개발자들이 발생된 출력 페이지, 컨트롤, HTTP 리스펀스를 메모리 안에 저장할 수 있게 하였습니다. 다음 웹의 요청에서 ASP.NET은 스크래치로 부터 출력을 다시 발생하는 것 대신에 메모리로부터 발생된 출력을 찾는 것에 의하여 훨씬 빠르게 내용을 처리합니다. 그러나, 이 접근은 제한이 있다. - 발생된 내용은 항상 메모리와 무거은 트래픽을 경험하고 있는 서버상에서 저장 되어져야 하고, 아웃풋 캐싱에 의하여 소비된 메모리는 다른 웹 어플리케이션으로 부터 메모리 수요를 경쟁 할 수 있습니다.
ASP.NET 4는 당신이 하나 또는 더 많은 커스텀 아웃풋 캐시 공급자들을 설정할 수 있게 아웃풋 캐싱에 확장성을 더했다. 아웃풋 캐쉬 공급자들은 HTML 지속하기 위한 저장 메커니즘을 사용 할 수 있습니다. 이것은 로컬 혹은 원격 디스크, 클라우드 스토리지, 그리고 분산 캐쉬 엔진을 포함 할 수 있는 다른 종류의 지속성있는 메커니즘을 위하여 커스텀 아웃풋 캐쉬 공급자들이 가능하도록 하였습니다.
당신은 새로운 System.Web.Caching.OutputCacheProvider 타입으로 부터 상속한 클래스로 custom output-cache provider를 만듭니다. 그리고 Web.config 파일 안에 outputCache 요소의 새로운 하부 공급자를 사용해서 그 생성자를 구성 할 수 있습니다. 다음의 예를 보세요.
ASP.NET 4에서 기본으로, 모든 HTTP 응답들, 랜더된 페이지들 그리고 컨틀롤들은 인메모리 아웃풋 캐쉬를 사용합니다. 앞의 예를 보면 defaultProvider 특성이 AspNetInternalProvider 으로 설정되어 있는 것을 볼 수 있습니다. 당신은 웹어플리케이션을 위해 사용된 default output-cache 공급자를 바꿀 수 있습니다. 그 방법은 defaultProvider 를 위한 다른 공급자이름을 구체화하는 것입됩니다.
덧붙여, 당신은 컨트롤당, 요청당 다른 다른 아웃풋 캐쉬 공급자들을 선택할 수 있습니다. 다른 웹 사용자 컨트롤들을 위해 다른 아웃풋캐쉬 공급자들을 선택하는 가장 쉬운 방법이 있습니다. 그것은 페이지 혹은 가리키는 컨트롤안에 새로운 providerName 특성을 선언적으로 사용하는 것입니다. 다음의 예를 보세요.
HTTP 요청들을 위한 다른 아웃풋캐쉬 공급자를 구체화하는 것은 약간 더 작업이 필요합니다. 선언적으로 그 공급자를 구체화하는것 대신에, 당신은 특별한 요청을 위해 사용할 공급자를 프로그래밍적으로 구체화하기 위한 Global.asax 파일 안에 새로운 GetOuputCacheProviderName 매소드를 오버라이드 하는 것으로 대신합니다. 다음의 예를 이것을 사용하는 법을 보여줍니다.
public override string GetOutputCacheProviderName(HttpContext context)
{
if (context.Request.Path.EndsWith("Advanced.aspx"))
return "DiskCache";
else
return base.GetOutputCacheProviderName(context);
}
ASP.NET 4에서 아웃풋캐쉬 공급자의 확장성으로, 당신은 지금 당신의 웹사이트들을 위한 더 적극적이고 더 영리한 아웃풋캐싱 전략을 추구할 수 있습니다. 예를들어, 그것은 디스크 상의 낮은 트래픽으로 얻은 페이지들을 캐싱하는동안 메모리 안에서 사이트의 Top 10 페이지를 캐쉬 할 수 있습니다.
어떤 웹 어플리케이션은 많은양의 데이타를 로드하고, 처음 요청을 처리하기 전에 값비싼 초기화 처리를 수행할 필요가 있습니다. ASP.NET의 초기버전에서 이러한 상황을 위하여, 당신은 ASP.NET 어플리케이션을 깨우기 위하여 커스텀 접근을 고안해야만 했습니다. 그런 다음에 Global.asax에서 Application_Load 매소드 동안 초기화 코드를 실행하였습니다.
이 시나리오는 직접적으로 지정하는 auto-start 라는 새로운 확장성있는 특징이 가능합니다. 단 ASP.NET이 Windows Server 2008 R2, IIS7.5 환경에서 작동할 때입니다. 그 auto-start 특징은 어플리케이션 풀을 시작하고, ASP.NET 어플리케이션을 초기화하고, HTTP 요청을 접수하는 동안 제어된 접근을 제공한다. auto-start 특징을 사용하기위하여, IIS 관리자는 applicationHost.config 파일에서 다음의 컨피그레이션을 사용하는것에 의하여 자동적으로 시작되기위하여 IIS7.5에서 어플리케이션 풀을 설정합니다.
IIS 7.5 서버가 콜드 스타트 되었거나 개별 어플리케이션 풀이 리사이클링 되었을 때, IIS7.5는 웹어플리케이션이 자동적으로 시작되는 것을 결정하기 위하여 applicationHost에서 그 정보를 사용합니다. 자동 시작을 위하여 기록된 각 어플리케이션을 위하여, IIS7.5는 ASP.NET에 요청을 보냅니다. 그것은 어플리케이션을 임시적으로 HTTP요청을 받아들이지 않는 동안의 상태에서 어플리케이션을 시작하기 위해서입니다. 그것이 이상태에 있을 때, ASP.NET은 preloadProvider 특성에 의하여 정의된 타입을 예를들어 보여주고(이전의 예에서 보여주었을 때), 그것의 public 엔트리 포인트를 부릅니다. 당신이 관리된 자동시작형을 필수적인 엔트리 포인트와 함께 아래 예처럼 IProcessHostPreloadClient interface 를 실행하는것에 의하여 창조합니다.
public class CustomInitialization : System.Web.Hosting.IProcessHostPreloadClient
{
public void Preload(string[] parameters)
{
// Perform initialization.
}
}
당신의 초기화 코드가 Preload 매소드에서 실행되고 메소드가 반환한 후에, ASP.NET 어플리케이션은 요청을 처리할 준비가 되어 있습니다. IIS5와 ASP.NET에서 자동시작 추가를 위해, 당신은 지금 처음 HTTP 요청을 처리하기 전에 값비싼 어플리케이션 초기화를 수행하는 것을 위해 잘 정의된 접근을 해야합니다. 예를 들어, 당신은 어플리케이션을 초기화하기 위한 새로운 자동시작 특징을 사용할 수 있고, 그런 다음에 어플리케이션이 초기화되고 HTTP 트래픽을 받을 준비하는 로드 밸런서에 신호를 보낼 수 있습니다.
검색 엔진에서 한물간 링크의 축적을 이끌 수 있는 시간이 지나 페이지나 다른 내용으로 이동하는 것은 웹어플리케이션에서의 공통적인 실행입니다. ASP.NET에서 개발자들은 전통적으로 새로운 URL로 요청을 포워딩하기 위하여 Response.Redirect 함수를 사용하여 오래된 URL 에서의 요청을 처리하였습니다. 그러나, Redirect 함수는 HTTP 302 Found(임시적 리다이렉트) 응답이라는 문제가 발생했습니다. 그 문제는 오래된 URL로 사용자들이 접근을 시도했을 때 여분의 HTTP 왕복에서 발생하였습니다.
ASP.NET 4는 다음의 예로 HTTP 301 Moved Permanently 응답 문제를 해결한 새로운 RedirectPermanent 도우미 함수를 추가했습니다:
RedirectPermanent("/newpath/foroldcontent.aspx");
영구적인 리다이렉트를 인정하는 검색 엔진과 다른 사용자 에이전트들은 그 내용을 포함하는 새로운 URL을 저장할 것이다. 그 내용은 임시 리다이렉트를 위한 브라우저에 의새러 불필요한 왕복을 제거한 것이다.
The Incredible Shrinking Session State (놀랍게 감소하는 세션상태)
ASP.NET은 웹 팜에서 세션 상태를 저장하기 위한 두 가지 기본 옵션을 제공합니다: 하나는 외부 프로세스의 세션 상태 서버를 요청하는 세션상태 제공자이고, 다른 하나는 MS-SQL 서버 데이터 베이스에서 데이터를 저장하는 세션상태 제공자입니다. 왜냐하면 두 옵션은 웹 어플리케이션의 작업자 프로세스 밖에서 상태 정보를 저장하는 것을 포함하는데, 세션 상태는 그것이 원거리 스토리지에 보내기 전에 연속 진행되어야 합니다. 개발자가 세션 상태에 꽤 많은 정보를 저장하는것에 의존하면서, 시리얼라이즈 된 데이터의 양이 아주 많이 성장할 수 있습니다.
ASP.NET 4는 두 종류의 외부프로세스 세션 상태 제공자를 위한 새로운 압축 옵션을 소개합니다. 다음의 예에서 보여진 CompressionEnabled 확인 옵션이 true로 설정 되었을 때, ASP.NET은 .NET Framework System.IO.Compression.GZipStream 클래스를 사용하는 것에 의하여 시리얼라이즈된 세션 상태를 압축할 것입니다.
ASP.NET 4은 어플리케이션의 URL의 길이를 확장하기 위한 새로운 옵션을 소개합니다. 이전 버전의 ASP.NET 은 URL경로 길이들이 (NTFS 파일 경로 제한에 기반한) 260 문자로 제한했습니다. ASP.NET 4에서 당신은 두가지 새로운 httpRuntime configuration 특성을 사용해서 당신의 어플리케이션을 위해 적절하게 이 제한을 증가 혹은 감소시키는 옵션을 사용할 수 있습니다.
(프로토콜, 서버이름, 쿼리스트링을 포함하지 않는 URL의 일부)경로를 더 길게 혹은 짧게 하기 위하여, maxRequestPathLength 특성을 수정합니다. 쿼리스트링을 더 길게 혹은 더 짧게 하기 위해서, maxQueryStringLength 특성의 값을 수정합니다.
ASP.NET 4 는 또한 URL문자 체크에 의하여 사용된 문자들을 당신이 확인 할 수 있게 합니다. ASP.NET 4 URL 경로 부분 안에서 잘못된 문자를 찾았을 때, 그것은 그 요청을 거절하고, HTTP 400 에러를 발생합니다. 이전 버전의 ASP.NET 4에서, URL문자 체크는 문자들의 고정된 셋의 문자들로 제한되어졌다. ASP.NET 4 에서 당신은 다음의 예를보면 httpRuntime configuration 요소의 새로운 requestPathInvalidChars 특성을 사용하여 유효한 문자 집단을 커스터마이즈 할 수 있습니다.
기본적으로 requestPathInvalidChars 특성은 올바르지 않은 것으로 7개의 문자들로 정의한다. ( 디폴트로 requestPathInvalidChars 에 정의된 문자열에서, '<','>','&' 문자들은 엔코딩 된다. 왜냐하면 Web.config 파일은 XML 파일이기 때문이다.)
당신은 필요에 따라 유효한 문자 집단을 커스터마이즈 할 수 있다.
Note: ASP.NET 4는 0x00에서 0x1F의 ASCII 영역에서의 문자들을 포함하는 URL경로를 거절합니다. 왜냐하면 그것들은 IETF의 RFC 2396 안에서 정의된 올바르지 않은 URL 문잘열들입니다. (http://www.ietf.org/rfc/rfc2396.txt). IIS 6을 운영하는 윈도우즈 서버 버전 혹은 그 이상에서, http.sys 프로토콜 디바이스 드라이버는 자동적으로 이 문자들과 함께 URL들을 거절합니다.
ASP.NET 요청 유효성은 XSS 공격에서 공통적으로 사용되는 문자열을 위하여 들어오는 HTTP 요청 데이터를 검색합니다. 만약 잠재적인 XSS 문자열이 발견된다면, 요청 유효성이 의심스러운 문자열을 알리고 에러를 반환한다. 내장 요청 유효성검사는 그것이 XSS 공격에서 사용된 가장 공통적인 문자열들을 찾았을 때, 단지 에러를 반환합니다. 더 공격적인 XSS 유효성 검사를 만들기 위한 이전의 시도는 매우 잘못된 상황을 야기시켰습니다. 그러나, 소비자들은 더 적극적인 요청 유효성 검사를 원하거나, 거꾸로 의도적으로 특별한 페이지 혹은 특별한 형태의 요청들을 위한 느슨한 XSS 검사를 원했습니다.
ASP.NET 4에서의 요청 유효성검사의 특징은 확장성이 있어서, 당신이 맞춤형 요청 유효성 검사 로직을 사용할 수 있습니다. 요청 유효성 검사를 확장하기 위하여, 당신은 새로운 System.Web.Util.RequestValidator 타입으로부터 상속 받는 클래스를 창조 할 수 있다. 그리고 당신은 맞춤형 타입을 사용하기 위하여 Web.config 파일의 httpRuntime 에서 어플리케이션을 설정합니다. 다음의 예는 커스텀 리퀘스트 유효성검사 클래스를 확인하는 법을 보여줍니다.
새로운 requestValidationType 의 특성은 스탠다드 닷넷 프레임워크 타입의 식별자 문자열을 요구한다. 그 식별자 문자열은 맞춤형 요청 유효성검사를 제공하는 클래스를 구체화하는 역할을 합니다. 각 요청을 위하여 ASP.NET은 들어오는 각각의 HTTP 요청 데이터를 처리하기위하여 맞춤형 타입을 요청합니다. 들어오는 URL, 모든 HTTP 헤더들(쿠키와 커스텀 헤더들) 그리고 엔티티 바디는 모두 맞춤형 요청 검사에 의한 정밀검사로 모두 가능하게 합니다. 다음 예를 보세요.
public class CustomRequestValidation : RequestValidator
{
protected override bool IsValidRequestString(
HttpContext context, string value,
RequestValidationSource requestValidationSource,
string collectionKey,
out int validationFailureIndex)
{
// ......
}
}
당신이 들어오는 HTTP 데이터를 검사하는 것을 원하지 않는 경우에는, 요청 유효성검사 클래스는 간단하게 base.IsValidRequestString.부르것에 의하여 ASP.NET의 디폴트 요청 유효성 검사가 작동하게 돌아 갈 수 있습니다.
첫 배포이후, ASP.NET은 강력한 인 메모리 객체 캐쉬(System.Web.Caching.Cache)를 포함했습니다. 그 캐쉬 실행은 매우 있기 있어서 웹어플리케이션이 아닌 곳에서도 사용되었습니다. 그러나 윈도우즈 폼 혹은 WPF 어플리케이션 ASP.NET의 객체 캐쉬를 사용 가능하게 한 System.Web.dll에서 참조하는 것은 어설펐습니다.
모든 어플리케이션들이 캐싱을 가능하게 하기위하여, 닷넷 프레임워크 4는 새로운 어셈블리, 새로운 네임스페이스, 베이스 타입, 실제적인 캐싱 실행을 소개합니다. 새로운 System.Runtime.Caching.dll 어셈블리는 새로운 System.Runtime.Caching 네임스페이스에서 새로운 캐싱 API를 포함합니다.
새로운 MemoryCache 클래스는 ASP.NET 캐쉬에 가깝게 만들어 졌고, 그것은 ASP.NET과 함께 많은 양의 내부 캐쉬 엔진 로직을 공유합니다. 비록 System.Runtime.Caching 안의 퍼블릭 캐싱 API들이 맞춤형 캐쉬들의 개발을 지원하기 위하여 업데이트 되었더라도, 당신이 ASP.NET 캐쉬 객체를 사용했다면, 당신은 새로운 API들에서 비슷한 개념을 찾을 것입니다. 새로운 MemoryCache 와 제공하는 기초 API들에 대한 면밀한 논의는 완벽한 문서를 요구할 것입니다. 그러나 다음의 예는 당신에게 새로운 캐쉬 API 어떻게 작동하는 지 알려줍니다. System.Web.dll 의존 없는 윈도우즈 폼을 위한 예입니다.
private void btnGet_Click(object sender, EventArgs e)
{
//Obtain a reference to the default MemoryCache instance.
//Note that you can create multiple MemoryCache(s) inside
//of a single application.
ObjectCache cache = MemoryCache.Default;
//In this example the cache is storing the contents of a file string
fileContents = cache["filecontents"] as string;
//If the file contents are not currently in the cache, then
//the contents are read from disk and placed in the cache.
if (fileContents == null)
{
//A CacheItemPolicy object holds all the pieces of cache
//dependency and cache expiration metadata related to a single
//cache entry.
CacheItemPolicy policy = new CacheItemPolicy();
//Build up the information necessary to create a file dependency.
//In this case we just need the file path of the file on disk.
List<string> filePaths = new List<string>();
filePaths.Add("c:\\data.txt");
//In the new cache API, dependencies are called "change monitors".
//For this example we want the cache entry to be automatically expired
//if the contents on disk change. A HostFileChangeMonitor provides
//this functionality.
policy.ChangeMonitors.Add(new HostFileChangeMonitor(filePaths));
//Fetch the file's contents
fileContents = File.ReadAllText("c:\\data.txt");
//And then store the file's contents in the cache
cache.Set("filecontents", fileContents, policy);
}
MessageBox.Show(fileContents);
}
Extensible HTML, URL, and HTTP Header Encoding
(확작성있는 HTML, URL 그리고 HTTP 헤더 엔코딩)
ASP.NET 4 에서 당신은 다음의 공통 텍스트-엔코딩 일을 위한 커스텀 엔코딩 루틴들을 창조 할 수 있습니다: HTML 엔코딩; URL 엔코딩; HTML 특성 엔코딩; 그리고 외부 HTTP 헤더들의 엔코딩. 당신은 새로운 System.Web.Util.HttpEncoder 타입으로 부터 상속받는 것과 Web.config 파일의 httpRuntime 섹션안에 커스텀 타입을 사용하기 위한 ASP.NET을 구성하는 것 에 의한 커스텀 엔코더를 창조 할 수 있습니다. 다음 예를 보세요.
커스텀 엔코더가 구성된 후에, ASP.NET은 자동적으로 public ASP.NET 엔코딩 함수인 System.Web.HttpUtility 혹은 System.Web.HttpServerUtility 클래스들이 불리어질 때마다 커스텀 엔코딩 실행을 호출합니다. 이것은 일부의 웹 개발팀이 적극적인 문자 엔코딩을 실행할 커스텀 엔코더를 창조할 수 있게 합니다. 그 동안 쉬는 웹 개발팀은 계속 ASP.NET 엔코딩 API들을 사용합니다. httpRuntime 요소안에 커스텀 엔코더를 중심으로 구성하는 것에 의하여, 당신은 모든 텍스트-엔코더가 public ASP.NET 엔코딩 함수들로부터의 호출들이 커스텀 엔코더를 통하여 라우트되는 것을 보장 받습니다.
하나의 서버상에 호스트 될 수 있는 웹사이트의 수를 증가시키기 위하여, 많은 호스터들은 하나의 작업자 프로세스 안에 다중의 ASP.NET 어플리케이션들을 운영하였습니다. 그러나 다중 어플리케이션들이 하나의 공유된 작업자 프로세스를 사용한다면, 서버 관리자들은 문제를 가지고 있는 개별 어플리케이션들을 확인하기가 어려울 것입니다.
ASP.NET 4는 CLR에 의해 소개된 새로운 자원 모니터링이 기능적으로 영향을 줍니다. 이 기능을 활성화 하기 위해서, 당신은 aspnet.config 구성정보 파일에 다음의 XML 구성정보 조각을 추가 할 수 있습니다.
Note: aspnet.config 파일은 .NET Framework가 인스톨 된 디렉토리 안에 있습니다. 그것은 Web.config 파일에 존재하지 않습니다.
appDomainResourceMonitoring 특징이 활성화 될었을 때, 두 개의 새로운 수행 카운터들이 "ASP.NET Applications" 수행 카테고리 안에서 가능합니다: % Managed Processor Time 와Managed Memory Used. 이 두 수행 카운터들은 새로운 CLR 어플리케이션-도메인 자원 관리 특성을 추정된 CPU 시간과 개별 ASP.NET 어플리케이션의 관리된 메모리 이용을 추적하기 위하여 사용합니다. 결과적으로 ASP.NET 4와 함께, 관리자들은 지금 하나의 작업자 프로세스 안에 동작하는 개별 어플리케이션의 자원 소비를 더 상세하게 볼 수 있습니다.
You can create an application that targets a specific version of the .NET Framework. In ASP.NET 4, a new attribute in the compilation element of the Web.config file lets you target the .NET Framework 4 and later. If you explicitly target the .NET Framework 4, and if you include optional elements in the Web.config file such as the entries for system.codedom, these elements must be correct for the .NET Framework 4. (If you do not explicitly target the .NET Framework 4, the target framework is inferred from the lack of an entry in the Web.config file.)
당신은 .NET Framework 특정 버전을 규정하는 어플리케이션을 창조할 수 있습니다. ASP.NET 4에서 Web.config 파일의 compilation 요소의 새로운 특성은 당신이 .NET Framework 4와 이전버전으로 규정하게 합니다. 당신이 명시적으로 .NET Framework 4를 설정하고, 당신이 system.codedom 위한 입력 같은 것을 Web.config 파일안에 선택적인 요소를 포함한다면, 이 요소들은 .NET Framework 4 위해 잘 작동할 것입니다.(만약 당신이 명시적으로 .NET Framework 4를 설정하지 않는다면, 목표 프레임워크는 Web.config 파일의 부족한 입력으로 추측을 합니다. )
다음의 예는 Web.config 파일의 compilation 요소안의 targetFramework 특성의 사용을 보여줍니다.
<compilation targetFramework="4.0"/>
Note the following about targeting a specific version of the .NET Framework:
.NET Framework의 특정버전을 지정하는 것에 대해 다음을 기억할 것:
만약 Web.config 파일이 targetFramework 특성을 포함하지 않거나 Web.config 파일을 분실했다면 .NET Framework 4 어플리케이션 풀안에서 ASP.NET 빌드 시스템은 목표로 .NET Framework 4를 취할 것입니다.
만약 당신이 targetFramework 특성을 포함하고, system.codeDom 요소가 Web.config 파일안에 적의 되어 있다면, 그 파일은 .NET Framework 4. 위한 올바른 입력을 포함해야합니다.
당신이 (빌드 환경같은)당신의 어플리케이션을 프리컴파일 하기위한 aspnet_compiler 명령어를 사용하고 있다면, 당신은 목표 프레임워크를 위한 aspnet_compiler 의 올바른 버전을 사용해야 합니다. 당신이 (빌드 환경같은)당신의 어플리케이션을 프리컴파일 하기위한 aspnet_compiler 명령어를 사용하고 있다면, 당신은 목표 프레임워크를 위한 aspnet_compiler 의 올바른 버전을 사용해야 합니다. .NET Framework 3.5와 이전 버전을 위해 컴파일하기 위해서 .NET Framework 2.0 (%WINDIR%\Microsoft.NET\Framework\v2.0.50727) 안에 위치한 컴파일러는 사용합니다. 그 프레임워크 혹은 최근 버전에서 창조된 어플리케이션을 컴파일하기 위해서는 .NET Framework 4 안에 위치한 컴파일러는 사용합니다.
At run time, the compiler uses the latest framework assemblies that are installed on the computer (and therefore in the GAC).
런타임에서, 컴파일러가 (GAC 안의 그결과와 )컴퓨터상에 인스톨된 최신 프레임워크 어셈블리들을 사용합니다. (예를 들어, 가상의 버전 4.1이 인스톨 된다면) 업데이트가 나중에 프레임워크에 만들어진다면, 비록 targetFramework 특성이 (4.0 같은) 낮은 버전을 가리키더라도 당신은 새로운 버전의 프레임워크에서 특징들을 사용할 수 있습니다. (그러나 Visual Studio 2010의 설계 시간에 혹은 당신이 당신이 aspnet_compiler 명령어를 사용할 때, 프레임워크의 새로운 특징을 사용하는 것은 컴파일러 에러를 일이킬 것입니다.
