Visual Studio 2010 공식 팀 블로그 @vsts2010

지난 7월 2일경 스캇구스리 옹의 블로그에서는 Razor 라는 새로운 view 엔진이 소개되었습니다. Razor 는 기존에 <%%> 으로 통칭되던 코드 블록을 좀더 간소화 시키기 위해 고안되었으며 , 스파케티 코드의 늪에서 허덕이는 개발자를 위해서 새로 고안되었습니다. 특히 이 코드블록은 기존에 미칠듯이 복잡하고 어려웠던 asp.net 인라인 코드를 좀더 html스럽게 보여줄수 있게되었다는 것에서 차별화 됩니다. 

스캇옹의 블로그 에서 Razor를 감상해BoA요

[기존 <%%> 코드블록으로 구성된 코드]

현재 우리가 이 Razor를 테스트 해볼수 있는 환경은 크게 두가지로 나뉠수 있습니다.

두번째는 ASP.NET 프로젝트에서 Microsoft.WebPages.dll 을 참조하는 것 입니다.

Razor in WebMatrix

현재 가장 빠르게 Razor 를 접해보는 방법은 WebMatrix 를 설치하는 것 입니다. 설치에 대한 부분은 준서아빠님이 소개해주셨으니 간략하게 넘어가도록 하겠습니다. 설치에 대해서는 WebMatrix 설치부터 HelloWorld까지 를 참조해 주시기 바랍니다.

WebMatrix 를 설치하게 되면 처음에 Website1 이라는 페이지가 생성되어 있는 것을 알수 있습니다. Razor 를 간단하게 살펴볼수 있는 데모프로젝트라고 이해하시면 될거 같습니다. ^^

WebSite1을 더블클릭하거나 선택하고 Ok 버튼을 클릭합니다.

깔끔한 웹 페이지가 나오네요. 이 페이지는 Razor 과 간단한 html 로 구성되어 있습니다. 그럼 한번 코드를 보도록 하겠습니다.

Files를 클릭하면 현재 구동중인 웹 사이트 프로젝트를 수정할수 있습니다. 이곳에서 우리는 default.cshtml 을 살펴보도록 하겠습니다.

해당 파일에서는 Twitter 위젯을 Razor 코드로 처리하고 있는 것을 확인할수 있습니다. Twitter 객체는 WebMatrix엔진에서 제공되는것으로 보입니다만 , 특별히 선언된 부분이나 참조되는 dll을 찾는 것은 조금 힘들어보였습니다. 또한 특정 벤더의 API를 사용 하는 부분은 효용성이 떨어지므로 , 데모 이외의 용도로 사용시 문제가 될수 있을것으로 보입니다.

이 페이지에서는 Twitter 의 검색어를 조회해서 보여주는 위젯을 선보여주고 있습니다만, 저는 이것보다는 제 트윗을 노출시키고자 합니다. 이를 위해 기존 코드를 간단하게 주석처리하고 제 트윗을 노출시켜보도록 하겠습니다.

이제 어플리케이션을 다시 구동시키면!

의도했던 트윗이 노출되는 것을 확인할수 있습니다. ^^

Summary

이번 글에서는 WebMatrix 에 포함된 기본 프로젝트에서 Razor 를 사용하는 부분과 함께 , 외부 함수를 끌어오고 기존의 프로그래밍 경험을 접목시켜보는 것을 보여드렸습니다. 다음 글에서는 외부 함수를 직접 구현하고 그 함수를 사용하는 방법에 대해 알아보도록 하겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

안녕하세요 박종혁입니다. 연말, 연초라고 너무 오래 쉬었군요. ㅠㅠ
새해복많이 받으세요~
 http://www.asp.net/learn/whitepapers/aspnet40/  사이트를 번역 세번째 시간입니다.

ASP.NET 1.0 릴리즈 이후 , 웹폼은 ASP.NET에서 핵심적인 특징을 가졌습니다. 다음을 포함하면서, ASP.NET 4는 많이 향상되었습니다.

• 메타 태그를 설정하는 능력.
• 뷰 스테이트에 더 많은 컨트롤.
• 브라우저의 능력을 사용하는 더 쉬운 방법들..
• 웹폼들을 함께 라우팅 하는 ASP.NET 사용에 대한 지원.
• 발생된 ID들에 더 많은 컨트롤.
• 데이터 컨트롤들 안에서 선택된 열들을 지속하는 능력.
• FormView  와 FormView 컨트롤들에서 랜더링된 HTML에 더 많은 컨트롤.
• 데이터 소스 컨트롤들을 위한 필터링된 지원.

Setting Meta Tags with the Page.MetaKeywords and Page.MetaDescription Properties

  ASP.NET 4 Web Forms에서 작은 추가가 이었는데, 그것은 Page 클래스의 두 속성 MetaKeywords 와MetaDescription 입니다. 이 두 속성들은 당신의 페이지 안에 부합하는 메타 태그를 다시 표현했습니다. 다음 예를 보세요.

이 두 속성들은 페이지의 Title 속성이 하던 것과 같은 방법으로 작동합니다. 그것들은 이 두 가지 규칙을 따릅니다.

1. 속성 네임을 대응하는 head  요소 안에 meta 태그들이 없다면(즉, Page.MetaKeywords 위하여 name="keywords" 이고 Page.MetaDescription 을 위하여 name="description" 이며, 이 속성들이 설정되지 않은 것을 의미합니다), meta 태그들은 그것이 랜더링 될 때, 그페이지에 추가 될 것입니다.
2.  이 이름들과 함께 이미 meta 태그들이 있다면, 이 속성들은 존재하는 태그들의 내용을 위한 get과 set 매소드로 활동합니다.

  당신은 런타임에서 이 속성들을 설정할 수 있습니다. 그것은 당신이 DB 혹은 다른 소스로부터 내용을 얻게하며, 당신이 특정 페이지들을 위한 것을 설명하기 위하여 동적으로 그 태그들을 설정하게 합니다. 당신은 또한 웹폼 페이지 마크업 맨 위에 @ Page 지시어에서 Keywords 와 Description 속성을 설정 할 수 있습니다. 다음 예를 보세요.

 이것은 페이지 내에서 이미 선언된 것이 있다면 meta 내용을 오버라이드 할 것입니다. 설명 meta 태그의 내용이 구글에서 향상된 검색 목록화 미리보기를 위하여 사용 됩니다. (부연 설명으로 구글 웹마스터 센트럴 블로그에서 Improve snippets with a meta description makeover 를 보세요) 구글과 윈도우 라이브 서치는 어떤 것을 위해서 키워드들의 내용을 사용하지 않습니다. 그러나 다른 검색 엔진은 가능 할 것입니다. 덧붙여 검색 엔진 가이드 웹사이트의 Meta Keywords Advice 를 보세요. 이 새로운 속성들은 간단한 특징입니다. 그러나 그것들은 당신이 이것들을 수동으로 추가할 필요가 있을 때 혹은  meta 태그를 만들기 위하여 당신 자신의 코드를 쓸 때 부담을 덜어 줄 것입니다.

Enabling View State for Individual Controls

  기본적으로 뷰 스테이트는 페이지에서 작동합니다. 결과적으로 페이지상의 각 컨트롤은 그것이 어플리케이션을 위해 필요하지 않다면 잠재적으로 뷰 스테이트를 저장합니다. 뷰 스테이트의 데이타는 페이지의 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 는 뷰스테이트가 필요한 컨트롤들을 차례로 포함합니다.

Changes to Browser Capabilities

  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 파일들을 만들거나 업데이트 할 수 있습니다.

\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

  당신이 브라우저 지원을 정의한 후에, 당신은 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 속성을 설정하는 법을 보여줍니다.

<system.web> 
<browserCaps provider="ClassLibrary2.CustomProvider, ClassLibrary2, 
  Version=1.0.0.0, Culture=neutral" /> 
</system.web> 

 
새로운 브라우저 지원 정의를 등록하는 다른 방법은 코드를 사용하는 것인데, 다음 예를 보세요. 

void Application_Start(object sender, EventArgs e) 
{ 
  HttpCapabilitiesBase.BrowserCapabilitiesProvider =
    new ClassLibrary2.CustomProvider();
   // ... 
 } 

  
  이 코드는 Global.asax 파일의 Application_Start 이벤트 안에서 동작합니다. 캐쉬가 결정된 HttpCapabilitiesBase 객체를 위한 유효한 상태로 남기위해서, BrowserCapabilitiesProvider 클래스에서 변화는 어플리케이션 실행 중 코드 전에 일어나야합니다. 
 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

  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 라이브러리의 최신 버전을 다운로드 할 수 있습니다.

  Microsoft Ajax 라이브러리는 컨트롤들을 만들기 위한 간단한 필수적인 문법을 지원합니다. 예를 들어, 당신은 ID가 Name인 HTML 요소에 client  워터마크를 덧붙이고 생서하는 다음의 간단한 코드를 생성할 수 있습니다.

  이 코드를 포함하는 HTML 문서가 웹 브라우저안에서 랜더링 되었을 때,워터마크는 다음의 예처럼 보여집니다. 

  당신이 Visual Studio 2008 혹은 Visual Studio 2010을 사용하면서 클라이언트 컨트롤을 만들었을 때, 당신은 입력 할때 인텔리센스를 사용할 수 있습니다.

Script Loader(스크립트 로더)

  Microsoft Ajax 라이브러리는 클라이언트-스크립트 로더를 포함합니다. 클라이언트-스크립트 로더는 자동적으로 클라이언트 컴포넌트 혹은  컨트롤에 의하여 요구된 모든 스크립를를 올립니다. 그리고 올바른 순서로 그 스크립트를 실행합니다.

클라이언트-스크립트 로더는 다음의 특징을 지원합니다:

• 스크립트에 의해 요구된 모든 리소스들을 자동적으로 로드합니다.
• 각 스크립트가 확실하게 단지 한번 로드되게 합니다.
• 동시에 스크립트들을 로드하고 스크립트를 조합하는 것에 의하여 성능을 향상시킵니다.
• 단지 필요할 때 스크립트를 로드하도록 지원합니다.
• jQuery 같은 제3의 스크립트들과 당신 자신의 스크립트들을 로드하도록 지원합니다.

  예를 들어, 다음의 코드는 클라이언트 워터마크 컨트롤에 의해 요구된 모든 스크립트들을 로드하기 위하여 스크립트 로더의 장점이 있습니다.

<script src="../Scripts/MicrosoftAjax/start.js" type="text/javascript"></script>
<script src="../Scripts/ACT/ACTRegisterExtended.js" type="text/javascript"></script> 
<script type="text/javascript">
 
    Sys.require(Sys.components.watermark, function() {
   
        Sys.create.watermark("#Name", {
            WatermarkText: "Add name here..."
        });
  
    });
 
</script>

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를 보세요.

Client Data Access(클라이언트 데이터 접근)

   Microsoft Ajax 라이브러리는 웹브라우저 상에서 완전히 동작하는 DB로 이루어진 웹 어플리케이션을 빌드 가능하게합니다. 클라이언트가 데이터에 접근 가능하게 하는 Microsoft Ajax의 3가지 특징이 있습니다.

• Client data controls
• Client templates
• Client data context 

  클라이언트 DataView 컨트롤은 하나의 혹은 다수의 데이터베이스 레코드를 보여 줄 수 있게 합니다. 당신은 클라이언트 템플릿을 만드는 것으로 DataView 컨트롤을 통하여 데이터 베이스 레코드들을 보여 줍니니다. 예를 들어, 당신은 모든 데이터베이스를 보여주는 다음의 코드처럼 코드를 사용할 수있습니다. 그 데이터베이스 레코드들은 MovieService라고 이름 붙여진 WCF 서비스로부터 찾게 될 수 있습니다. 

    예제 속의 자바스크립트 코드는 모든 스크립트를 로드하기 위하여 클라이언트-스크립트를 사용합니다. 그 스크립트들은 DataView  컨트롤과 MovieService WCF 서비스로 부터 데이터를 찾기 위한 DataView 컨트롤에 의하여 사용된 DataContext 컨트롤의해 필요했습니다. 다음 DataView  컨트롤은 생성되고, ID moviesView를 갖는 HTML UL요에 덧붙여졌습니다. 클라이언트 템플릿은 페이지의 바디안에 포함되고, 다음과 같습니다:

<ul id="moviesView">     
    <li>{{Title}} - {{Director}}</li> 
</ul>

  
  DataView 컨트롤은 클라이언트 템플릿과 함께 WCF 서비스로부터 찾아진 각 데이터베이스 레코드를 구성합니다.  {{Title}} 플레이스홀더는 Movie 값을 보여줍니다. Title 속성과 {{Director}} 플레이스홀더는 Movie.Director 속성 값을 보여줍니다. 당신이 위 문서를 필요할 때, 다음의 페이지는 웹브라우저에서 렌더링 됩니다.

 

당신은 다양한 다른 데이터 소스로 부터 찾아진 데이터를 보여줄 수 있습니다.

• ASP.NET (.asmx) Web services.
• WCF Web services.
• ADO.NET Data Services.
• Anything that returns JSON-formatted data.

Client DataContext and AdoNetDataContext Classes

   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 Integration( jQuery 통합)

   jQuery 라이브러리는 아주 인기있는 오픈소스 자바스크립트 라이브러리 이며, ASP.NET 웹폼과 ASP.NET MVC 안에 모두 포함되어 있습니다. Microsoft Ajax 라이브러리는 jQuery 개발자들에게 마음에 들도록 설계되었습니다. 당신은 jQuery 플러그인과 Microsoft Ajax 클라이언트 컨트롤들을 같은 Ajax 어플리케이션에서 문제없이 함께 사용 할 수 있습니다.

  예를 들어, 다음 페이지에서 Microsoft Ajax 워터파크 컨트롤은 당신이 jQuery 플러그인으로 만들려고 사용했을 때 처럼 같은 문법을 사용하면서 창조 되었습니다.

   jQuery $(".required") 섹터는 요구한 CSS 클래스를 가진 페이지로 부터 모든 요소를 찾기위하여 사용 되었습니다. 워터마크는 매칭하는 모든 요소에 덧붙여 졌습니다. Microsoft Ajax 라이브러리가 jQuery 체이닝을 지원하는 것을 알려줍니다. 워터마크가 jQuery 섹터에 의하여 반환된 요소들에 적용된 후에, 매치되는 모든 요소의 배경색과  두드러진색이 바뀌어졌습니다. jQuery 섹터에 의하여 반환된 같은 wrapped set에 반하여,  다중의 연산들이 수행 되었습니다. 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Core Services   (핵심 서비스들)

ASP.NET 4는 아웃풋 캐싱과 새션상태 저장 같은 ASP.NET의 핵심 서비스를 향상시킨 많은 특징들을 소개합니다.

  Web.config 파일은 웹 어플리케이션을 위한 구성정보를 포함하고 있는데, AJAX, 라우팅, IIS 7과 함께 인티그레이션 같은 새로운 특징들이 추가되었기 때문에 닷넷 프레임워크의 과거 일부 릴리즈들 보다 꽤 늘어났습니다. 이것은 비쥬얼 스튜디오 같은 툴 없이 새로운 웹어플리케이션을 구성하거나 시작하는데 더 어렵게 만들었습니다. 닷넷 프레임워크 4에서 주요한 구성정보들은 machine.config 파일로 이동하게 되었고, 어플리케이션들은 지금 이 설정들을 상속합니다. 이것은 빈 공간으로 남겨 두던지 아니면 단지 어플리케이션이 목표로하는 프레임워크의 버전이 무엇인지를 비주얼 스튜디오를 위하여 명시하는 다음의 줄들을 ASP.NET 4 어플리케이션들 안의 Web.config에 남겨주기만 하면 됩니다.

Extensible Output Caching   (확장성있는 아웃풋 캐싱)

  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 특성을 선언적으로 사용하는 것입니다. 다음의 예를 보세요.   

<%@ OutputCache Duration="60" VaryByParam="None" providerName="DiskCache" %> 

  HTTP 요청들을 위한 다른 아웃풋캐쉬 공급자를 구체화하는 것은 약간 더 작업이 필요합니다. 선언적으로 그 공급자를 구체화하는것 대신에, 당신은 특별한 요청을 위해 사용할 공급자를 프로그래밍적으로 구체화하기 위한 Global.asax 파일 안에 새로운 GetOuputCacheProviderName 매소드를 오버라이드 하는 것으로 대신합니다. 다음의 예를 이것을 사용하는 법을 보여줍니다.

  ASP.NET 4에서 아웃풋캐쉬 공급자의 확장성으로, 당신은 지금 당신의 웹사이트들을 위한  더 적극적이고 더 영리한 아웃풋캐싱 전략을 추구할 수 있습니다. 예를들어, 그것은 디스크 상의 낮은 트래픽으로 얻은 페이지들을 캐싱하는동안 메모리 안에서 사이트의 Top 10 페이지를 캐쉬 할 수 있습니다.

자세한 예시 설명은 http://vsts2010.net/84 에 구자승님의 기사를 보시기 바랍니다.

Auto-Start Web Applications ( 자동시작 웹 어플리케이션)

  어떤 웹 어플리케이션은 많은양의 데이타를 로드하고, 처음 요청을 처리하기 전에 값비싼 초기화 처리를 수행할 필요가 있습니다. 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에서 어플리케이션 풀을 설정합니다.

  왜냐하면 하나의 어플리케이션 풀은 다수의 어플리케이션을 포함 할 수 있기 때문에, 우리는 applicationHost.config 파일에서 다음의 컨피그레이션을 사용하는것에 의하여 자동적으로 시작되는 개별적인 어플리케이션을 구체화합니다.

  IIS 7.5 서버가 콜드 스타트 되었거나 개별 어플리케이션 풀이 리사이클링 되었을 때, IIS7.5는  웹어플리케이션이 자동적으로 시작되는 것을 결정하기 위하여 applicationHost에서 그 정보를 사용합니다. 자동 시작을 위하여 기록된 각 어플리케이션을 위하여, IIS7.5는 ASP.NET에 요청을 보냅니다. 그것은 어플리케이션을 임시적으로 HTTP요청을 받아들이지 않는 동안의 상태에서 어플리케이션을 시작하기 위해서입니다. 그것이 이상태에 있을 때, ASP.NET은 preloadProvider  특성에 의하여 정의된 타입을 예를들어 보여주고(이전의 예에서 보여주었을 때), 그것의 public 엔트리 포인트를 부릅니다.  당신이 관리된 자동시작형을 필수적인 엔트리 포인트와 함께 아래 예처럼 IProcessHostPreloadClient interface 를 실행하는것에 의하여 창조합니다. 

  당신의 초기화 코드가 Preload  매소드에서 실행되고 메소드가 반환한 후에, ASP.NET  어플리케이션은 요청을 처리할 준비가 되어 있습니다. IIS5와 ASP.NET에서 자동시작 추가를 위해, 당신은 지금 처음 HTTP 요청을 처리하기  전에 값비싼 어플리케이션 초기화를 수행하는 것을 위해 잘 정의된 접근을 해야합니다. 예를 들어, 당신은 어플리케이션을 초기화하기 위한 새로운 자동시작 특징을 사용할 수 있고, 그런 다음에 어플리케이션이 초기화되고 HTTP 트래픽을 받을 준비하는 로드 밸런서에 신호를 보낼 수 있습니다.

Permanently Redirecting a Page (영원히 페이지를 리다이렉트 하는 것)

  검색 엔진에서 한물간 링크의 축적을 이끌 수 있는 시간이 지나 페이지나 다른 내용으로 이동하는 것은 웹어플리케이션에서의 공통적인 실행입니다. 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 클래스를 사용하는 것에 의하여 시리얼라이즈된 세션 상태를 압축할 것입니다.

Web.config 파일에 새로운 특성을 간단하게 추가하는 것으로 웹 서버들에서 여분의 CPU 사이클들과 함께 어플리케이션은 시리얼라이즈 된 세션상태 정보의 양이 줄어 든 것을 깨닫습니다.

Expanding the Range of Allowable URLs (허용한 URL 범위 확장)

  ASP.NET 4은 어플리케이션의 URL의 길이를 확장하기 위한 새로운 옵션을 소개합니다.  이전 버전의 ASP.NET 은 URL경로 길이들이 (NTFS 파일 경로 제한에 기반한) 260 문자로 제한했습니다. ASP.NET 4에서 당신은 두가지 새로운 httpRuntime configuration 특성을 사용해서 당신의 어플리케이션을 위해 적절하게 이 제한을 증가 혹은 감소시키는 옵션을 사용할 수 있습니다.

  다음의 예는 이 새로운 특성들을 보여줍니다.

<httpRuntime maxRequestPathLength="260" maxQueryStringLength="2048" /> 

(프로토콜, 서버이름, 쿼리스트링을 포함하지 않는 URL의 일부)경로를 더 길게 혹은 짧게 하기 위하여, maxRequestPathLength 특성을 수정합니다. 쿼리스트링을 더 길게 혹은 더 짧게 하기 위해서, maxQueryStringLength 특성의 값을 수정합니다. 

  ASP.NET 4 는 또한 URL문자 체크에 의하여 사용된 문자들을 당신이 확인 할 수 있게 합니다. ASP.NET 4 URL 경로 부분 안에서 잘못된 문자를 찾았을 때, 그것은 그 요청을 거절하고, HTTP 400 에러를 발생합니다. 이전 버전의 ASP.NET 4에서, URL문자 체크는 문자들의 고정된 셋의 문자들로 제한되어졌다. ASP.NET 4 에서 당신은 다음의 예를보면 httpRuntime configuration 요소의 새로운 requestPathInvalidChars 특성을 사용하여 유효한 문자 집단을 커스터마이즈 할 수 있습니다.

<httpRuntime requestPathInvalidChars="<,>,*,%,&,:,\" /> 

기본적으로 requestPathInvalidChars 특성은 올바르지 않은 것으로 7개의 문자들로 정의한다. ( 디폴트로 requestPathInvalidChars 에 정의된 문자열에서, '<','>','&' 문자들은 엔코딩 된다. 왜냐하면 Web.config 파일은 XML 파일이기 때문이다.)

당신은 필요에 따라 유효한 문자 집단을 커스터마이즈 할 수 있다.

Extensible Request Validation (확장성있는 요청 유효성)

ASP.NET 요청 유효성은 XSS 공격에서 공통적으로 사용되는 문자열을 위하여 들어오는 HTTP 요청 데이터를 검색합니다. 만약 잠재적인 XSS 문자열이 발견된다면, 요청 유효성이 의심스러운 문자열을 알리고 에러를 반환한다. 내장 요청 유효성검사는 그것이 XSS 공격에서 사용된 가장 공통적인 문자열들을 찾았을 때, 단지 에러를 반환합니다. 더 공격적인 XSS 유효성 검사를 만들기 위한 이전의 시도는 매우 잘못된 상황을 야기시켰습니다. 그러나, 소비자들은 더 적극적인 요청 유효성 검사를 원하거나, 거꾸로 의도적으로 특별한 페이지 혹은 특별한 형태의 요청들을 위한 느슨한 XSS 검사를 원했습니다.

  ASP.NET 4에서의 요청 유효성검사의 특징은 확장성이 있어서, 당신이 맞춤형 요청 유효성 검사 로직을 사용할 수 있습니다. 요청 유효성 검사를 확장하기 위하여, 당신은 새로운 System.Web.Util.RequestValidator  타입으로부터 상속 받는 클래스를 창조 할 수 있다. 그리고 당신은  맞춤형 타입을 사용하기 위하여 Web.config 파일의 httpRuntime 에서 어플리케이션을 설정합니다. 다음의 예는 커스텀 리퀘스트 유효성검사 클래스를 확인하는 법을 보여줍니다. 

<httpRuntime requestValidationType="Samples.MyValidator, Samples" /> 

  새로운 requestValidationType 의 특성은 스탠다드 닷넷 프레임워크 타입의 식별자 문자열을 요구한다. 그 식별자 문자열은 맞춤형 요청 유효성검사를 제공하는 클래스를 구체화하는 역할을 합니다. 각 요청을 위하여 ASP.NET은 들어오는 각각의 HTTP 요청 데이터를 처리하기위하여 맞춤형 타입을 요청합니다. 들어오는 URL, 모든 HTTP 헤더들(쿠키와 커스텀 헤더들) 그리고 엔티티 바디는 모두 맞춤형 요청 검사에 의한 정밀검사로 모두 가능하게 합니다. 다음 예를 보세요.

  당신이 들어오는 HTTP 데이터를 검사하는 것을 원하지 않는 경우에는, 요청  유효성검사 클래스는 간단하게 base.IsValidRequestString.부르것에 의하여 ASP.NET의 디폴트 요청 유효성 검사가 작동하게 돌아 갈 수 있습니다.

Object Caching and Object Caching Extensibility (객체 캐싱과 객체 캐싱의 확장성)

 첫 배포이후, ASP.NET은 강력한 인 메모리 객체 캐쉬(System.Web.Caching.Cache)를 포함했습니다. 그 캐쉬 실행은 매우 있기 있어서 웹어플리케이션이 아닌 곳에서도 사용되었습니다. 그러나 윈도우즈 폼 혹은 WPF 어플리케이션 ASP.NET의 객체 캐쉬를 사용 가능하게 한 System.Web.dll에서 참조하는 것은 어설펐습니다.

  모든 어플리케이션들이 캐싱을 가능하게 하기위하여, 닷넷 프레임워크 4는 새로운 어셈블리, 새로운 네임스페이스, 베이스 타입, 실제적인 캐싱 실행을 소개합니다. 새로운  System.Runtime.Caching.dll 어셈블리는 새로운 System.Runtime.Caching 네임스페이스에서 새로운 캐싱 API를 포함합니다. 

네임스페이스는 두 개의 핵심 클래 셋을 포함한다.

• 어떤 타입의 맞춤형 캐쉬 실행을 빌드하기 위한 기반을 제공하는 추상화 형태.
• 유형의 in-memory 객체 캐쉬 실행( System.Runtime.Caching.MemoryCache 클래스).

  새로운 MemoryCache 클래스는  ASP.NET 캐쉬에 가깝게 만들어 졌고, 그것은 ASP.NET과 함께 많은 양의 내부 캐쉬 엔진 로직을 공유합니다. 비록 System.Runtime.Caching 안의 퍼블릭 캐싱 API들이 맞춤형 캐쉬들의 개발을 지원하기 위하여 업데이트 되었더라도, 당신이 ASP.NET 캐쉬 객체를 사용했다면, 당신은 새로운  API들에서 비슷한 개념을 찾을 것입니다. 새로운 MemoryCache 와 제공하는 기초 API들에 대한 면밀한 논의는 완벽한 문서를 요구할 것입니다. 그러나 다음의 예는 당신에게 새로운 캐쉬 API 어떻게 작동하는 지 알려줍니다. System.Web.dll 의존 없는 윈도우즈 폼을 위한 예입니다.

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을 구성하는 것 에 의한 커스텀 엔코더를 창조 할 수 있습니다. 다음 예를 보세요.

<httpRuntime encoderType="Samples.MyCustomEncoder, Samples" /> 

   커스텀 엔코더가 구성된 후에, ASP.NET은 자동적으로 public ASP.NET 엔코딩 함수인 System.Web.HttpUtility 혹은 System.Web.HttpServerUtility 클래스들이 불리어질 때마다 커스텀 엔코딩 실행을 호출합니다. 이것은 일부의 웹 개발팀이 적극적인 문자 엔코딩을 실행할 커스텀 엔코더를 창조할 수 있게 합니다. 그 동안 쉬는 웹 개발팀은 계속 ASP.NET 엔코딩 API들을 사용합니다. httpRuntime 요소안에 커스텀 엔코더를 중심으로 구성하는 것에 의하여, 당신은 모든 텍스트-엔코더가 public ASP.NET 엔코딩 함수들로부터의 호출들이 커스텀 엔코더를 통하여 라우트되는 것을 보장 받습니다.
 

Performance Monitoring for Individual Applications in a Single Worker Process (하나의 작업자 프로세스 안에 개별 에플리케이션들을 위해 모니터링하는 수행)

  하나의 서버상에 호스트 될 수 있는 웹사이트의 수를 증가시키기 위하여, 많은 호스터들은 하나의 작업자 프로세스 안에 다중의 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와 함께, 관리자들은 지금  하나의 작업자 프로세스 안에 동작하는 개별 어플리케이션의 자원 소비를 더 상세하게 볼 수 있습니다.

Multi-Targeting (다중 목표)

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 명령어를 사용할 때, 프레임워크의 새로운 특징을 사용하는 것은 컴파일러 에러를 일이킬 것입니다. 

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

- 이번엔 웹디자이너와 배포에 대해서

부족한 번역이지만, 이번엔 웹 디자이너와 배포에 대해서 적어볼까 합니다.


- Visual Studio 2010 Web Designer Improvement

Visual Studio 2010의 웹페이지 디자이너는 더 뛰어난 CSS 호환성, HTML과 ASP.NET 마크업의 코드조각에 대한 추가적인 지원과 Jscript를 위해서 다시 디자인된 인텔리센스등으로 더 향상된 기능을 제공합니다.

- Improved CSS Compatibility

Visual Studio 2010의 Visual Web Developer 디자이너는 CSS 2.1 표준과 호환되는데요. 이 디자이너는 HTML 소스와의 통합성을 높이면서 기존의 버전의 Visual Studio보다 전체적으로 더 견고한 기능을 제공합니다. 내부적으로는 앞으로 추가될 렌더링, 레이아웃, 사용성 및 유지보수를 위한 설계적인 측면에서의 향상도 있었습니다.

- HTML and Jscript Snippets

HTML에디터는 인텔리센스를 이용해서 태크이름을 자동완성합니다. 그리고 인텔리센스의 코드조각 기능이 전체 태그와 기타 부분을 완성합니다. VisualStudio 2010에서는 인텔리센스의 코드조각 가능이 C#과 Visual Basic에 적용되었던 것 처럼 Jscript에 대해서도 지원될 것입니다.

VisualStudio 2010에는 200개 이상의 코드조각이 ASP.NET과 HTML의 일반적인 태그와 필요한 속성(runat=”server” 같은)과 특정 태그들에 공통적인 속성들(ID, DataSourceID, ControlToValidate, Text같은)의 자동완성을 도와줍니다.

추가적인 코드조각들을 다운받을 수 있으며, 팀의 공동작업이나 개인작업에 공통으로 쓰이는 마크업의 블록을 코드조각으로 뽑아내서 사용할 수도 있습니다.

- Jscript IntelliSense Enhancements

VisualStudio 2010에선 더 풍부한 편집을 위해서 Jscript의 인텔리센스가 다시 디자인 되었습니다. 이젠 인텔리센스가 registerNamespace같은 메서드나 기타 비슷한 자바스크립트 프레임워크의 기술을 이용해서 동적으로 생성되는 객체를 인식할 수 있습니다. 그리고 방대한 스크립트 라이브러리를 분석하고 화면에 인텔리센스를 표시하는데 걸리는 시간을 사용자가 거의 못 느낄 정도로 향상시켰습니다. 호환성 역시 대단히 향상되어서 외부 라이브러리나 다양한 코딩 스타일도 지원할 수 있게 되었습니다. 문서화를 위한 주석은 타이핑하는 즉시 파싱되어서 인텔리센스에서 바로 활용할 수 있습니다.

- Web Application Deployment with Visual Studio 2010

현재 웹 어플리케이션을 배포하는 작업은 우리가 꿈꾸었던 것만큼 쉽지 않았죠. ASP.NET 개발자는 종종 아래와 같은 문제에 직면하곤 합니다.

*   FTP같은 기술을 사용해야 하는 공동 호스팅 사이트에 배포하는 경우. 게다가 데이터베이스를 세팅하기 위한 SQL스크립트를 직접 실행해야 하거나 가상 디렉토리같은 IIS세팅도 바꿔야 한다.

*   엔터프라이즈 환경에서는 웹 어플리케이션을 배포하는 것으로 끝나지 않고, ASP.NET 설정파일이나 IIS세팅도 수정해야 한다. 데이터베이스 관리자는 데이터베이스를 돌리기 위해 필요한 SQL스크립트를 돌려야 한다. 그런 설치작업은 종종 몇 시간을 잡아먹으며 노동에 가까운 일이 되며, 세세하게 문서화 되어야 한다.

VisualStudio 2010은 웹 어플리케이션을 중단없이 배포할 수 있게 도와주는 새로운 기술을 통해서 이런문제들을 해결합니다. 이런 기술들중의 하나가 IIS Web Deployment Tool(MsDeploy.exe)이죠.

VisualStudio 2010에서 웹배포에 관련된 요소들은 아래와 같이 크게 분류할 수 있습니다.

*   Web packaging

*   Web.config Transformation

*   Database deployment

*  One-Click Publish for Web applications

아래의 섹션들에서 하나씩 자세하게 설명을 해보겠습니다.

- Web Packaging

VisualStudio 2010에서는 MSDeploy 툴을 사용해서 어플리케이션을 압축해서 압축파일(.zip)을 생성하는데, 그 파일을 웹 패키지라고 부릅니다. 패키지파일은 어플리케이션에 대한 메타데이터와 아래의 내용들을 포함합니다.

*   어플리케이션 풀 세팅과 에러페이지 세팅, 등등을 포함하는 IIS세팅

*   웹페이지와 사용자 정의 컨트롤, 정적인 컨텐츠(이미지와 HTML파일), 등등을 포함하는 실제 웹 컨텐츠

*   SQL 서버의 데이터베이스 스카마와 데이터

*   보안 인증서, GAC에 설치할 컴포넌트, 레지스트리 세팅, 등등

웹 패키지는 아무 서버에나 복사할 수 있고, IIS 매니저를 사용해서 수동으로 설치할 수 있습니다. 또는, 커맨드라인 명령어나 배포API를 사용해서 자동으로 배포할 수도 있습니다.

VS2010에서는 웹패키지를 만들기 위해서 사용가능한 MSBuild의 task와 target을 제공합니다. 더 많은 정보는 Vishal Joshi의 블로그에 있는 10 + 20 reasons why you should create a Web Package를 참조하시길 바랍니다.

- Web.config Transformation

웹 어플리케이션의 배포를 위해서 VisualStudio 2010에서는 XML Document Transform (XDT)가 도입되었는데, 이 요소는 개발설정에서 Web.config를 읽어와서 제품설정(production setting)으로 변환하게 도와줍니다. 변환에 관련된 세팅은 변환파일인 web.debug.config, web.release.config, 그리고 기타파일(이 파일들의 이름은 MSBuild 설정과 매치된다)등에 명시되어 있습니다. 변환파일에는 Web.config파일을 배포하기 위해 필요한 수정사항들만 포함되어 있습니다. 이런 수정사항들을 간단한 문법으로 명시해주면 되는거죠.

아래의 예제는 배포의 릴리즈설정에 의해 생성가능한 web.release.config파일의 일부분인데요. 예제의 내용중에서 Replace키워드를 보면, 배포과정에서 Web.config파일의 connectionString 노드의 값이 어떻게 바뀌어야 하는지 명시해주고 있습니다.

<connectionStrings xdt:Transform="Replace">

  <add name="BlogDB" connectionString="connection string detail]" />

</connectionStrings>

더 자세한 정보는, Vishal Joshi의 블로그의 Web Deployment: Web.Config Transformation를 보시면 됩니다.

- Database Deployment

VisualStudio 2010의 배포 패키지에는 SQL 서버 데이터베이스에 대한 의존성 역시 포함될 수 있습니다. 패키지 정의의 일부분으로 원본 데이터베이스의 연결문자열을 명시해줄 수 있습니다. 웹 패키지를 만들때 VisualStudio2010에 의해서 데이터베이스 스키마와 선택적으로 데이터에 대해서 SQL 스크립트가 만들어지고 패키지에 포함됩니다. 사용자 정의 SQL 스크립트를 만들어서 서버에서 순차적으로 실행되어야 할 순서를 지정해줄 수도 있습니다. 배포할때, 타겟 서버에 대한 연결문자열을 제공하고, 배포 프로세스에서 이 연결문자열을 이용해서 해당 데이터베이스에 SQL 스크립트를 실행해서 데이터베이스 스키마를 만들고 데이터를 추가합니다.

추가적으로, One-Click Publish를 이용하면 어플리케이션이 원격의 공용 호스트에 게시된 후에 데이터베이스를 직접적으로 게시할 수 있도록 배포를 설정할 수 있습니다. 자세한 내용은 Vishal Joshi의 블로그의 Database Deployment with VS 2010를 참조하시면 됩니다.

- One-Click Publish for Web Application

VisualStudio 2010에서는 IIS 원격 관리 서비스를 이용해서 원격의 서버에 웹 어플리케이션을 게시할 수 있도록 도와줍니다. 게시를 위해서 호스팅 계정이나 테스트 서버나 스테이징 서버를 위한 게시 프로파일(publish profile)을 생성할 수 있습니다. 각각의 프로파일은 안전하게 계정정보를 저장할 수 있구요. 그러면 Web One Click Publish 툴바를 이용해서 한번의 클릭으로 타겟서버에 배포할 수 있게 됩니다. VisualStudio2010에서는 MSBuild 커맨드 라인을 통해서도 배포할 수 있는데요. 이 기능을 통해서 지속적인 통합 모델을 이용하는 팀 빌드 환경에 게시작업을 포함할 수 있습니다.

더 자세한 정보는, Vishal Joshi의 블로그의 Web 1-Click Publish with VS 2010를 보시면 되구요, VisualStudio 2010에서의 웹 어플리케이션 배포에 대한 비디오 영상을 보려면, Vishal Joshi의 블로그의  VS 2010 for Web Developer Previews를 보시면 됩니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

- Entity Templates

Entity Templates를 이용하면 사용자 정의 페이지를 만들지 않고도 데이터의 레이아웃을 사용자가 편집할 수 있습니다. 페이지 템플릿은 FormView 컨트롤(기존 버전의 Dynamic Data의 페이지 템플릿에서 사용하던 DetailView컨트롤 대신에)과 DynamicEntity 컨트롤을 사용해서 Entity templates를 렌더링합니다. 이렇게 하면 사용자는 Dynamica Data가 렌더링한 마크업에 대해서 더 많은 제어를 할 수 있게 되죠.

아래의 목록은 Entity templates를 포함하고 있는 새로운 프로젝트 폴더의 구조입니다.

\DynamicData\EntityTemplates

\DynamicData\EntityTemplates\Default.ascx

\DynamicData\EntityTemplates\Default_Edit.ascx

\DynamicData\EntityTemplates\Default_Insert.ascx

EntityTemplates폴더는 모델 객체들을 어떻게 화면에 표시할지에 대한 템플릿을 담고 있습니다. 기본적으로 객체들은 ASP.NET 3.5 SP1의 Dynamic Data에서 생성된 DetailsView의 마크업과 유사한 모양의 마크업을 생성해주는 Default.ascx를 이용해서 렌더링되는데요. 다음의 예제는 Default.ascx 컨트롤의 마크업 입니다.

<asp:EntityTemplate runat="server" ID="TemplateContainer1">

  <ItemTemplate>

    <tr

      <td>

        <asp:Label ID="Label1" runat="server" OnInit="Label_Init" />

      </td>

      <td>

        <asp:DynamicControl runat="server" OnInit="DynamicControl_Init" />

      </td>

    </tr>

  </ItemTemplate>

</asp:EntityTemplate>

기본 템플릿은 전체 사이트의 디자인과 느낌을 바꾸기 위해서 수정가능합니다. 기본 템플릿에는 디스플레이, 수정, 그리고 삽입을 위한 템플릿이 포함되어 있습니다. 새로 추가하는 템플릿들은 데이터객체의 이름을 기반으로 해서 추가될 수도 있는데, 그 타입의 객체의 디자인과 느낌을 수정하고 싶을때가 그렇습니다. 예를들면, 아래와 같은 템플릿을 추가할 수 있습니다.

\DynamicData\EntityTemplates\Products.aspx

이 템플릿은 아래와 같은 마크업을 포함하고 있겠죠.

<tr>

  <td>Name</td>

  <td><asp:DynamicControl runat="server" DataField="ProductName" /></td>

  <td>Category</td>

  <td><asp:DynamicControl runat="server" DataField="Category" /></td>

</tr>

새로운 Entity templates는 DynamicEntity 컨트롤을 사용하는 페이지에서 화면에 나타납니다. 런타임에 이 컨트롤은 Entity template의 내용으로 대체되는데요. 아래의 마크업은 Entity template를 사용하는 Detail.aspx 페이지 템플릿의 FormView컨트롤입니다. 마크업의 DynamicEntity 요소을 주목해서 보시죠.

<asp:FormView runat="server" ID="FormView1"

    DataSourceID="DetailsDataSource"

    OnItemDeleted="FormView1_ItemDeleted">

  <ItemTemplate>

    <table class="DDDetailsTable" cellpadding="6">

      <asp:DynamicEntity runat="server" />

      <tr class="td">

        <td colspan="2">

          <asp:DynamicHyperLink ID="EditHyperLink" runat="server"

              Action="Edit" Text="Edit" />

          <asp:LinkButton ID="DeleteLinkButton" runat="server"

              CommandName="Delete"

              CausesValidation="false"

              OnClientClick='return confirm("Are you sure you want to delete this item?");'

              Text="Delete" />

        </td>

      </tr>

    </table>

  </ItemTemplate>

</asp:FormView>

- New Field Templates for URLs and E-mail Addresses

ASP.NET 4 에서는 새로운 내장 필드 템플릿인 EmailAddress.ascx, Url.ascx가 추가되었습니다. 이 템플릿들은 DataType 속성과 함께 EmailAddress나 Url로 선언된 필드에 사용됩니다. EmailAddress타입의 객체의 경우에는 필드가 ‘mailto:protocol’를 사용해서 만든 하이퍼링크로 표시되구요, 사용자가 이걸 클릭하면 사용자의 이메일 클라이언트 프로그램을 실행하고 기본메세지를 생성해줍니다. Url타입의 객체는 그냥 일반적인 하이퍼링크로 표시되구요.

아래의 예제는 필드를 마크하는 방법을 보여줍니다.

[DataType(DataType.EmailAddress)]

public object HomeEmail { get; set; }

[DataType(DataType.Url)]

public object Website { get; set; }

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

- 이건 또 뭥미

이 포스트 시리즈는 http://www.asp.net/learn/whitepapers/aspnet40/ 에 올라와있는 "ASP.NET 4.0 and Visual Studio 2010 Web Development Beta 2 Overview"를 번역하는 시리즈입니다. 번역이라서 조금은 딱딱할 수도 있고, 내공의 부족으로 제대로 번역이 힘든 부분도 있습니다.(반드시 있습니다-_-) 따쓰한 피드백으로 격려를 부탁드립니다. 냐하하하하. 두부분으로 나눠서 번역을 맡았는데요, 제가 맡은 부분은 Dynamic Data, Studio 2010 Web Designer Improvement, Web Application Deployment with Visual Studio 2010 이렇게 세부분입니다. 그럼 시작해볼까효?


- Dynamic Data

Dynamic Data는 2008년 중반에 릴리즈되었던 .NET 프레임워크 3.5 서비스팩 1에서 처음 소개가 됐습니다. 이 기술은 데이터 중심 개발을 하는데 있어서 많은 유용한 기능을 제공하는데요. 예를 들면 아래와 같습니다.

l  데이터 중심의 웹사이트를 RAD(빠른 속도의 어플리케이션 개발)처럼 작성

l  데이터 모델에 명세된 제약조건을 기반으로 자동으로 유효성검사

l  Dynamic Data 프로젝트의 일부인 필드 템플릿을 이용해서 GridView와 DetailsView의 자동생성된 필드의 마크업을 쉽게 변경할 수 있음

더 상세한 정보는 MSDN에 있는 Dynamic Data documentation을 참조하시면 됩니다.

ASP.NET 4 에선 기존의 기능보다 더 강력해진 지원으로 데이터중심의 웹사이트를 더 빠르게 개발할 수 있도록 도와줍니다.

- Enabling Dynamic Data for Existing Projects

.NET 프레임워크 3.5 서비스팩 1 에 추가되었던 Dynamic Data는 아래와 같은 새로운 기능들을 소개했었죠.

l  필드 템플릿 – 데이터 바운드 가능한 컨트롤에 대해서 데이터 타입에 기반한 템플릿을 제공한다. 필드 템플릿은 기존에 각각에 필드에 템플릿 필드를 이용해서 설정해줘야 하던것에 비해서 컨트롤의 모양을 입맛에 맞게 커스터마이즈하는 좀 더 간편한 방법을 제공한다.

l  유효성검사 – 데이터 클래스에 어트리뷰트를 이용해서 값의 유무, 범위 체크, 타입 체크, 정규식을 이용한 패턴매칭, 사용자 정이 유효성검사와 같은 일반적인 경우에 대한 유효성검사를 명시해줄 수 있다.

하지만, 이런 기능들은 아래와 같은 요구사항이 있었습니다.

l  데이터 엑세스 레이어는 반드시 Entity Framework나 LINQ to SQL이어야 한다.

l  데이터 소스 컨트롤은 EntityDataSource나 LinqDataSouce컨트롤 이 두가지 외에는 지원되지 않는다.

l  위와 같은 기능들을 모두 사용하기 위해서는 필요한 파일들이 모두 포함된 템플릿인 Dynamic Data나 Dynamic Data Entities를 통해 생성된 웹 프로젝트여야만 했다.

ASP.NET 4에 추가될 Dynamic Data에서 가장 초점을 둔 부분중의 하나는 어떤 ASP.NET 어플리케이션이라고 해도 Dynamic Data의 기능을 활용할 수 있도록 한다는 것 입니다. 아래의 예제코드는 이런 목표에 맞게, 기존에 존재하던 페이지에 Dynamic Data의 기능을 활용하기 위해서 명시해줘야 하는 코드입니다.

<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="True"

    DataKeyNames="ProductID" DataSourceID="LinqDataSource1">

</asp:GridView>

<asp:LinqDataSource ID="LinqDataSource1" runat="server"

    ContextTypeName="DataClassesDataContext" EnableDelete="True" EnableInsert="True"

    EnableUpdate="True" TableName="Products">

</asp:LinqDataSource>

페이지의 코드비하인드에서 이 컨트롤들의 Dynamic Data기능을 켜려면 아래와 같은 코드를 반드시 추가해야 합니다.

GridView1.EnableDynamicData(typeof(Product));

GridView 컨트롤이 수정모드에 있을 때, 사용자가 입력한 값이 적절한 포맷인지 아닌지를 Dynamic Data가 자동으로 검사를 하고, 포맷에 맞지 않는다면 에러메세지를 보여줍니다.

이 기능은 입력모드에서 사용될 기본값을 명시해줄 수 있는 것 같이 다른 장점도 가지는데요. Dynamic Data를 쓰지 않고 필드의 기본값을 설정하려면, 이벤트를 걸어야 되고, FindControl등의 메서드를 이용해서 컨트롤을 찾아야 되고, 값을 설정해야 하는등의 작업을 해야합니다. 하지만 ASP.NET 4에서는, EnableDynamicData메서드에서 아래의 예제코드에서 처럼 어떤 필드에도 기본값을 설정해줄 수 있습니다.

DetailsView1.EnableDynamicData(typeof(Product), new { ProductName = "DefaultName" });

- Declarative DynamicDataManager Control Syntax

다른 ASP.NET컨트롤들이 그렇듯이 DynamicDataManager컨트롤도 이제는 코드에서 뿐만 아니라 선언적으로 속성을 명시해줄 수 있게 개선되었습니다. 아래 예제에서 DynamicDataManager 컨트롤의 마크업을 확인할 수 있습니다.

<asp:DynamicDataManager ID="DynamicDataManager1" runat="server"

    AutoLoadForeignKeys="true">

  <DataControls>

    <asp:DataControlReference ControlID="GridView1" />

  </DataControls>

</asp:DynamicDataManager>

<asp:GridView id="GridView1" runat="server"

</asp:GridView>

이 마크업은 DataControls섹션에 나와있듯이 GridView1에 Dynamic Data기능을 적용시킵니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

New Feature of Ajax

ATLAS라는 코드명으로 2006년 ASP.NET에 추가된 Ajax가 점점 견고해 지고 있습니다. 2006년 CTP버전 이었던 ATLAS를 겁없이(?) 프로젝트에 적용했었던 기억이 떠오르는 군요. 2006년을 기억하면, 참 MS에서 새로운 기술이 쏟아져 나오던 한해 였습니다. Vista가 공개 되고 WinFX와 WPF, WF(그때는 WWF 로 소개 되었었죠), WCF, ASP.NET에 Ajax 등등 많은 기술이 소개되어 .NET 개발자들의 정신 건강을 악화시켰던 때였습니다.
Ajax는 Google을 선두로 하여 Web 2.0에 적절한 패러다임을 제공하였으며, 국내에서도 많은 파장을 일으켰습니다. 특히, MS에서 나온 Ajax는 개발자의 개발 편의성을 확장시켜 Ajax 대중화에 큰 역활을 하였습니다.

이번 ASP.NET 4.0에 Ajax는 Data Provider의 접근 용이성에 중점을 둔듯 합니다. WCF와 ADO.NET을 이용하여 Client Based Development를 확장시켰으며, DataView는 Client Side에서 개발자가 편하게 화면을 개발 할 수 있도록 리스트 컨트롤을 제공하고 있습니다.

Client Template Rendering - DataView

DataView는 이번에 추가된 기능으로 이전까지는 Server Control을 이용한 리스트를 제공한 반면, Client Side Control을 사용함으로써, Server의 부하를 줄일 수 있도록하는 기능입니다. 예전에는 반복문을 통해 DOM을 생성한다든지, 아니면 개발자 자신의 라이브러리를 활용하거나, Third party 솔루션을 이용하는 방법이 있었습니다만, System.Web.Extention 4.0버전 부터는 기본적으로 DataView라는 컨트롤을 제공해 주고 있습니다. 그리고, 굳이 ASP.NET 언어가 아닌 다른 Framework에서도 사용가능한 독립형 스크립트로 제공하여 주고 있어 플랫폼 대한 제약을 많이 완화 시켰습니다.

참      고 : Use jQuery and ASP.NET AJAX to build a client site Repeater
다운로드 : Microsoft ASP.NET AJAX  4.0 Preview

간략하게 기능을 알아보도록 하겠습니다.

선언적 구문으로 생성하는 DataView

WebSite 프로젝트를 생성하고 간단한 html문서 또는 aspx 문서를 생성해 보겠습니다. <head>섹션에

<script type="text/javascript" src="../MicrosoftAjax/MicrosoftAjax.debug.js"></script><script type="text/javascript" src="../MicrosoftAjax/MicrosoftAjaxTemplates.debug.js"></script>

<body xmlns:sys="javascript:Sys" xmlns:dataview="javascript:Sys.UI.DataView" sys:activate="*">

<ul id="testDataView" class="sys-template" sys:attach="dataview" dataview:data="{{ testData }}">        <li>            <span class="name">{{ Name }}</span>            <span class="value">{{ Value }}</span>        </li></ul>

은 Template에 바인딩이 일어나기 전까지 Template을 숨기는 예약된 스타일이라고 정의하겠습니다. 

그리고, sys:attatch는 또 뭐하는 아이이길래 우리를 헷깔리게 하는 것일까요? 음, 예전에 Microsoft AJAX Library를 프로그래밍적으로 다루어 보셨던 분들이라면 생소 하지 않는 $Create라는 메서드를 기억하실 겁니다. 이놈은 개체를 생성하는 아이인데 Sys.으로 파생되는 개체들을 생성하는 메서드라고 할 수 있습니다. 즉 Microsoft AJAX Library에서만 파생된 개체들을 쉽게 생성하고자 만들어진 메서드입니다. 그럼 sys:attatch와 $Create와는 무슨 관계일까요? 답은 같은 놈입니다. 다만 선언적으로 태그의 Attribute에 위치하느냐, 프로그래밍적으로 접근하느냐하는 방법의 차이일 뿐이지 같은 의미를 지녔습니다. 마지막으로 dataview:data는 body태그에서 Namespace를 정의해 주었던거 생각 나시죠? 그 접두어에 data는~~~~~~~ 네 맞습니다. Data Source입니다. 우리가 리스트를 주욱 바인딩 할 데이터 소스 개체를 정의해 주는 Attribute입니다.
그럼, 이제 어느정도 Attribute에 대한 이해가 되었으리라 생각하고 다음 코딩으로 넘어 가겠습니다.

Add array DataSource

다음과 같이 Array로 DataSource를 생성합니다. 다음에는 ADO.NET과 WCF로 바인딩하는 포스팅을 하도록 하겠습니다.

<script type="text/javascript">        
var testData = [
            { Name: "홍길동", Value: "의적" },
            { Name: "김혜자", Value: "영화배우" },
            { Name: "원빈", Value: "영화배우" },
            { Name: "김태희", Value: "이쁜이" },
            { Name: "전지현", Value: "절세미인" },
            { Name: "2PM", Value: "가수" },
            { Name: "장동건", Value: "영화배우." },
            { Name: "카라", Value: "귀염둥이들" },
            { Name: "이수근", Value: "코메디언" },
            { Name: "강호동", Value: "돼랑이" },
            { Name: "유재석", Value: "메뚜기" },
            { Name: "이효리", Value: "횰" },
            { Name: "정형돈", Value: "정체불명" },
            { Name: "길", Value: "가수" }        ];
</script>

다들 아시겠지만 굳이 부연 설명 드리도록 하겠습니다. javascript는 함수형 언어로써 강력한 기능을 제공합니다. 보시는 바와 같이 단순히 Array 이지만 testData라는 개체에 Name과 Value라는 Attribute가 있는 개체들의 집합이 들어 가게 되는 것입니다. 우리가 생각 하는 new의 연산자와 javascript의 new 연산자는 다른 의미라는 것을 알고 계실 듯 합니다. 여기에서도 유추를 하실 수 있습니다. 혹, testData[0].Name일 경우 홍길동이 나타나는 결과를 얻으실 수 있습니다.
이제 실제 결과 페이지를 보고 이번 포스팅을 마무리 하겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.