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

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


- 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를 보시면 됩니다.

 

- 이어서 이어서!

지난 시간에 이어서 Dynamic Data에 관련된 기능들을 보시겠습니다.



- 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; }

  

- Creating Links with the DynamicHyperLink Control

 

Dynamic Data는 사용자가 웹사이트가 접근했을 때 보여지는 URL을 컨트롤하기 위해서 .NET 프레임워크 3.5 SP1에 추가되었던 라우팅 기능을 사용합니다. DynamicHyperLink 컨트롤이 Dynamic Data를 사용한 사이트에 접근하는 링크를 쉽게 만들 수 있도록 도와줍니다. 아래의 예제는 DynamicHyperLink컨트롤을 사용하는 예제입니다.

 

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

    Action="List" TableName="Products">

  Show all products

</asp:DynamicHyperLink>

 

이 마크업은 Global.asax파일에 정의된 규칙대로 라우팅되는 링크를 만들고, 그 링크는 Products테이블의 List페이지를 가리킵니다. DynamicHyperLink컨트롤은 컨트롤이 위치한 Dynamic Data 페이지에 기반해서 자동으로 테이블의 이름을 명시해줍니다.

 

 

- Support for Inheritance in the Data Model

 

현재 Entity Framework LINQ to SQL 둘다 모두 데이터 모델상에서의 상속을 지원합니다. 예를 들면, InsurancePolicy 테이블이 있는 데이터베이스를 생각해볼 수 있는데요. 추가로 InsurancePolicy와 동일한 필드를 가지고 몇가지 추가적인 필드만 가지는 CarPolicy HousePolicy테이블도 가질 수 있습니다. Dynamic Data는 이렇게 데이터 모델에서 상속관계를 갖는 객체에 대해서 scaffolding을 할 수 있도록 개선되었습니다.

 

 

- Support for Many-to-Many Relationships(Entity Framework Only)

 

엔티티 프레임워크는 다대다 관계를 가지는 테이블을 풍부한 기능으로 지원하고 있고, 관계를 엔티티 객체들간의 컬렉션으로 노출하는 형태로 구현이 되어있습니다. ManyToMany.ascx ManyToMany_Edit.ascx 필드 템플릿은 다대다 관계를 갖는 데이터를 표시하고 수정하는 걸 지원하기 위해서 추가되었습니다.

 

 

- New Attributes to Control Display and Support Enumerations

 

DisplayAttribute를 통해서 필드가 어떻게 화면에 표시될지를 추가적으로 컨트롤 할 수 있습니다.기존 Dynamic Data버전에 있던 DisplayName 속성은 필드의 캡션으로 쓰일 이름을 변경할 수 있도록 지원했었는데요. 새로운 DisplayAttribute 클래스는 필드를 표시하는데 있어서 필드의 데이터를 어떻게 정렬할 것인지, 필드에 필터를 적용할 것인지 같은 옵션을 제공합니다. 그리고 이 속성은 추가적으로 GridView컨트롤의 레이블, DetailsView컨트롤의 이름, 필드의 도움말, 필드의 워터마크(필드가 텍스트입력을 받는다면)등에 대한 독립적인 제어를 제공합니다.

 

EnumDataTypeAttribute 클래스는 필드를 열거형데이터 타입에 연결해주기 위해서 추가되었습니다. 이 속성을 필드에 주게되면, 열거형 타입을 명시하게 되는데요. Dynamic Data에서는 열거형 값을 표시하고 수정하는데 Enumeration.ascx를 사용합니다. 이 템플릿은 데이터의 값을 열거형의 이름과 연결합니다.

 

 

- Enhanced Support for Filters

 

Dynamic Data 1.0boolean열과 외래키열에 대한 내장필터를 갖고 릴리즈 되었었습니다. 하지만,이 필터들은 열을 화면에 표시할지, 열의 데이터를 어떤 순서로 출력할지 명시해줄 수는 없었는데요. 새로운 DisplayAttribute 속성은 이 문제를 화면에 열을 필터로 표시할지 그리고 어떤 순서로 표시할지 설정할 수 있게 함으로써 해결해줍니다.

추가적으로 향상된 부분은 필터링을 지원하는 부분이 웹폼의 QueryExtender를 이용하도록 재작성됐다는 점입니다. 이로써 필터가 사용될 데이터 소스 컨트롤을 몰라도 필터를 작성할 수 있습니다. 이런 확장과 더불어서 이젠 필터도 템플릿 컨트롤로 작성되게 되어서 새로운 필터를 작성해서 추가할 수 있게 되었습니다. 마지막으로, DisplayAttribute 클래스는 UIHint가 기본적인 필드템플릿을 오버라이드할 수 있게 지원하는 것 처럼, 기본적인 필터를 오버라이드할 수 있도록 지원합니다.



- 마치면서

다음번에는 웹 디자이너와 배포에 어떤 새로운 기능들이 추가되고 개선되었는지에 대해서 말씀드리겠습니다!

- 이건 또 뭥미

이 포스트 시리즈는 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기능을 적용시킵니다.



- 마치면서

쫌 이상해 보이긴 하네요-_-ㅋ 다음 포스트에서는 Entity Templates부터 시작해서 템플릿에 대한 내용을 설명드리도록 하겠습니다.

[ASP.NET 4.0] 2. AJAX - Declarative Client Template Rendering

ASP.NET 4.0 2009. 7. 8. 17:43 Posted by 알 수 없는 사용자
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에서도 사용가능한 독립형 스크립트로 제공하여 주고 있어 플랫폼 대한 제약을 많이 완화 시켰습니다.


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

선언적 구문으로 생성하는 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>

AJAX Template을 사용하려면 이 스크립트 참조를 꼭 기입하여야 정상적으로 Template이 생성되는 보실 수 있습니다. 그리고 Body 부분에 해당 Namespace와 Command를 추가해 줍니다.
<body xmlns:sys="javascript:Sys" xmlns:dataview="javascript:Sys.UI.DataView" sys:activate="*">
xmlns:sys="javascript:Sys"는 Sys라는 Namespace를 등록 시켜 줌으로써 선언적(Declarative) 또는 명령적(Imperative)인 모든 Template을 활성화 하는데 필요합니다. 아마도 Ajax를 프로그래밍적으로 접근 하셨던 분들은 Microsoft Ajax Library의 Namespace가 Sys. 이렇게 접두어를 붙여 사용되는 것을 보셨겁니다. 그리고 나머지 두 Attribute는 선언적(Declarative)으로 활성화하거나 바인딩 하는데 필요한 Attribute입니다. dataview또한 네임스페이스로써 Sys.UI.DataView의 AJAX 컨트롤을 의미합니다. 그리고 sys:activate="*"라는 Attribute는 페이지 로드시에 Template을 바인딩하는 특정 개체를 의미하는데 '*'(Asterisk)를 편의상 어떤것이든 활성화 하겠다는 뜻이고 만약 pane1, panel2에 Template을 바인딩 하려면 sys:activate="panel1, panel2"라고 명시적으로 코딩하시면 됩니다.
그리고 실제 Template이 들어갈 개체의 코드를 구현하여 보겠습니다.

<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>
ul안에 id와 class 그리고 sys:attach, dataview:data와 같은 예전에 보던 Attribute와 생전 처음 쌩뚱 맞은 Attribute가 ul 태그 안에 들어와 있는 것을 보실 수 있습니다. 일단 "sys-template"이 거슬리는 군요.
sys-template은 일종에 예약된 스타일이라고 이해하시면 됩니다. 만약 Template을 구현 하고 class에 sys-template을 명시적으로 넣어 주시지 않으시면, 효과가 즉빵 나타납니다. 어떤 효과일까요? 리스트가 아예 안나옵니다. 헐~ 필자도 처음에는 내 나름대로의 스타일을 줬다가 몇분 삽질하고, 이런 교훈을 얻었습니다. 아무튼  testStyleSheet.css스타일 시트를 만드셨다면 그 시트 안에는 .sys-template { display:none; } 이라는 스타일이 있어야 합니다. 다시 정리 하자면 sys-template 은 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일 경우 홍길동이 나타나는 결과를 얻으실 수 있습니다.
이제 실제 결과 페이지를 보고 이번 포스팅을 마무리 하겠습니다.

[ASP.NET 4.0] 1. Core Service - Extensible Output Caching

ASP.NET 4.0 2009. 6. 24. 20:03 Posted by 알 수 없는 사용자
Evolution of ASP.NET

.NET Framework 4.0 beta 1와 함께 ASP.NET도 새로운 변화를 시도하였습니다. ASP.NET 2.0의 변화 보다는 덜 파격적이지만, 그 동안 .NET Framework 업데이트가 진행되는 동안 ASP.NET의 변화가 미미했던 것을 감안 한다면, 이번 .NET Framework 4.0 업데이트와 함께 동승한 ASP.NET의 업데이트는 놀라울 만큼 바뀌었습니다.(스캇 구스리 아저씨가 힘좀 쓰셨나 봅니다.ㅋㅋ)
그 중 Core Service 업데이트는 Performance 측면과 기존 ASP.NET Issue를 처리하는데 두드러진 발전을 이루어 냈습니다. 그럼, Core Service의 주요 업데이트 사항을 간략하게 소개하고 넘어가도록 하겠습니다.

1. Extensible Output Caching - 확장 가능한 출력 캐쉬 정도로 직역하겠습니다. 기존에도 있던 페이지 캐싱을 개발자 나름대로 커스트마이징 할 수 있도록 확장 시켜준 기능입니다.
2. Auto-Start Web Application - HTTP Request에 대하여 콜드 스타트 또는 개별 응용프로그램의 재사용에 소모되는 비용을 절감하기 위한 기능인 듯 합니다. 왜 ASP.NET 맨처음 띄우면 밥먹고 담배피고 와야 하잖아요.(오바입니다만...) 그런 비용을 절감 하기 위해 나온 기술인듯합니다. 허나, Windows Server 2008 R2에 탑재 가능한 IIS 7.5에서만 지원되는 기능이라니 OTL이 아닐 수 없습니다. 한 3년동안은 이 기술 볼 수 없을 듯합니다.(회사에서 2008을 깔아야 뭘 하죠? 아직 2000 쓰는 곳도 많이 있는데....)
3. Permanently Redirecting a Page - 영원히 헤어지는 이전 페이지와의 관계, 참 무슨 영화 제목 같 군요. 이전에 이슈가 되었던 Request가 여러번 일어나던 오래된 페이지에서 Redirect를 시킬 경우 HTTP 302 요청 이슈에 대한 대처 방안입니다. 이건 뭐 다들 아실만한 내용이겠네요.
4. The Incredible Shrinking Session State - 깜놀하게하는 세션 상태정보의 감소로 의역(?)하죠. ASP.NET 에서 단일 서버라면 모르지만, 웹팜(Web farm - 모르신다면 당장 찾아 보세요. 롸잇 놔우)에서는 세션 상태 정보를 저장하기 위해서 세션 State Server를 구성하거나 MS SQL을 이용하여 세션 정보를 저장할 수  있도록 저장소를 두는 방법이 있었습니다. 근데, 문제는 두 State Server 다 거의 Raw데이타에 가까운 정보들이 날(Raw)로 저장되어 엥간한 동시접속자 수를 자랑하는 사이트에서는 엄청난 데이터량이 문제였습니다. 데이터 양도 문제지만 Network Traffic도 데이터 양 비례하게 올라가는 문제를 양산하게 됐죠. 이를 해결하기 위해 Gzip Compression을 사용했다는 군요.
그럼, 본격적으로 Extensible Output Caching에 대해 알아 보도록 하겠습니다.



What is Extensible Output Caching?  

말 그대로 확장 가능한 출력 캐쉬 기능입니다. 쉽게 설명 하자면, 엄연히 Caching 기능은 ASP.NET 1.0부터 있었습니다. 페이지나 컨트롤, HTTP Response의 출력물(뭐 쉽게 말하자면 컴파일러에서 html 코드로 완전히 변환된 상태의 코드)을 서버의 메모리 내에 상주시킴으로써 재생산에 드는 비용을 감소 시키는 데에 일조 하던 기능입니다. 하지만, 이것도 만만찮게 다른 문제를 일으키고는 했는데요 저장소는 무조건 메모리로 박치기 하다보니, 다른 웹 어플리케이션과 메모리 선점 전쟁을 하게 되는 문제가 생기고, 서버 자체적으로는 쓰잘때기 없는 것(일명 쓸애기) 까지 메모리 영역을 점령함으로써 서버 리소스를 잡아먹게 되는 문제가 생긴 것이지요.

그래서, 기존에 있던 기능은 살리고~ 살리고~ 살리고 살리고 살리고 커스텀한 Provider만 Implement(구현)하여 대체 저장소를 선택할 수 있도록 한 기능입니다. 물론 MS SQL 서버에도 저장이 되도록 기능을 갖추고 있습니다.

그럼 실전으로 들어가 정확히 뭐하는 기능인지 코드로 살펴 보도록 하겠습니다.

Walkthrough : Step 1. Create a Web Project

웹 프로젝트를 그림 1-1 과 같이 선택하여 생성합니다.

<그림 1-1>

<그림 1-2>

자~! 여기까지는 많이 하셨을 테니 거두 절미 하고, 솔루션에 CustomOutputCacheProvider Class를 추가하기 위해 클래스 라이브러리 프로젝트를 생성하도록 하겠습니다.
                                                                                                                   <그림 1-3>
                                                                                                                                    <그림 1-4>

프로젝트를 생성하셨다면 TestCustomOutputCacheProvider 클래스를 추가 시킵니다. 그리고, CustomOutputCacheProvider 프로젝트에 System.Web과 System.Confihuration을 참조 추가 시키겠습니다. 이제 어느정도 구색이 갖추어졌습니다.

Walkthrough : Step 2. Implement OutputCacheProvider

이번 단계에서는 개발자 특정 저장소를 지정할 수 있도록 커스텀한 CacheProvider를 생성도록 하겠습니다.

<그림 1-5>

그림 1-5와 같이 System.Web.Caching.OutputCacheProvider 추상 클래스를 Implement할 경우 자동으로 오버라이드 메서드가 생성되는 것을 볼수 있습니다.
                                                                                                                           <그림 1-6>

기능 구현에 많은 시간을 할애 할 수 없는 관계로 간단하게 세션에다가 캐싱을 하도록 구현 하겠습니다. 저장소를 선택하고 구현 하는 부분은 각자 구미가 땡기는 대로 구현하여 보세요.

Walkthrough : Step 3. Setting WebSite

먼저 그림 1-7과 같이 Web.Config파일에 caching 섹션을 추가하고 Provider 섹션을 구성하도록 하겠습니다.
<그림 1-7>
 
여기서 부연 설명 드리겠습니다. <outputCache> 섹션의 Attribute인 defaultProvider는 Web Application에 기본적으로 제공할 OutputCacheProvider입니다. 나중에 나올 Global.asax에서 설정해 주지 않는 이상 자동적으로 AspNetInternalProvider를 제공합니다. 그리고 하위 섹션인 <providers> 섹션 이하 섹션에는 개발자가 커스텀 하게 만들어 놓은 Provider를 넣는 부분입니다. 복수 개의 CacheProvider를 제공할 수 있어 좀 더 성능 향상에 기여 할 수 있습니다.(점점 말투가 딱딱해 지고 있습니다. 퇴근 시간이 훌쩍 넘어서 인지 정신적 압박이...)

그리고나서, Global.asax를 추가 시켜보도록 하겠습니다. 그림 1-8과 같이 새로운 아이템 추가 버튼을 클릭하면 대화 상자에서 Global.asax파일을 선택하여 확인 버튼을 선택합니다.
                                                                                                     <그림 1-8>

추가된 Global.asax 파일을 열고 그림 1-9의 코드를 추가 시켜 줍니다.
                                                                                                                       <그림 1-9>

 
GetOutputCacheProviderName 메서드는 Web.config 파일에 <caching>섹션이 추가 되어 있어야만 호출 되는 메서드 입니다. 그리고 코드를 보면 특정 페이지 에만 "SessionCache"라는 Provider명을 리턴하게 되어 있는데 이 부분은 Web.config의 <provider> 하위 노드의 Name Attribute와 매핑되는 키값입니다. 즉, 특정 페이지에 접근 시 개발자가 원하는 CacheProvider에 접근하여 커스텀한 저장소에 저장하게 하는 기능의 Entry Point 라고 보셔도 무방합니다.

그리고 UserControl을 생성하여 간단한 컨트롤을 작성하여 보겠습니다. 그리고 UserControl 선언적 구문 페이지 상단에는 <%@ OutputCache Duration="60" VaryByParam="None" providerName="SessionCache" %>
을 기입하여 줍니다. Duration의 의미는 소멸되기 까지 대기 시간으로 60초이고 VaryByParam은 Post든 QuerString이든 파라미터가 넘어오는 건마다 페이지를 저장시킬지의 여부를 선택합니다. 그리고 providerName은 해당 UserControl에서 제공할 Provider를 선택하는 Attribute입니다다.
그리고, 한가지 재미 있는점은 여러개의 Provider를 구현 하고 Web.config에 등록 시킨 후 각각 UserControl에 다른 Provider를 등록 시키면 Global.asax에서 한가지 ProviderName을 리턴 하더라도 각각의 Provider 저장소에 저장이 된다는 것입니다.

이제 마지막으로 웹 프로젝트에 CustomOutputCacheProvider 프로젝트를 참조한다. 그림 1-10r과 같이 전체적인 Test 솔루션 구성이 끝이 났습니다.

                                                                                                   <그림 1-10>

Walkthrough : Step 4. Running Web Application and Result

이제 마지막 단계 Test Application을 구동하고 값을 확인하는 작업만 남겨두고 있습니다. F5를 눌러 빌드를 한 후 정상적으로 빌드 성공이 되면 Web browser가 화면에 나타날 것 입니다. 제가 값을 확인 하기 위해 몇개 중단점을 찍어 값을 확인 하는 것으로 이번 아티클을 마무리 할까 합니다.

맨 처음 브라우저가 화면에 나타나고 그림 1-11처럼 Global.asax의 GetOutputCacheProviderName메서드에 중단 점이 걸리는 것을 확인 할 수 있습니다.
                                                                                                                              <그림 1-11>
그 다음 F5를 다시한번 눌러 다음 중단점으로 이동하면  우리가 만들어 놓은 TestCustomOutputCacheProvider 클래스의 Set메서드를 호출하는 것을 확인 할 수 있습니다.

                                                                                                                              <그림 1-12>
Text Visualizer로 값을 확인한 결과 그림 1-13과 같이 렌더된 Html 태그값이 저장소에 저장되는 것을 확인 할 수 있습니다.

                                                                                                         <그림 1-13>
마지막으로 인위적으로 포스트 백을 일으켜 저장소에 저장된 값을 가지고 오는 과정을 확인 하도록 하겠습니다. 화면에 버튼 이벤트를 일으키면 서버 쪽 Global.asax의 GetOutputCacheProviderName메서드를 재 호출 하여 페이지에 할당된 ProviderName을 리턴받은 후 TestCustomOutputCacheProvider 클래스의 Get메서드를 호출하는 것을 확인 할 수 있습니다. Get메서드에서는 이미 저장소에 캐싱된 Html 값이 반환 되어 사용자에게 전달되는 것을 확인 할 수 있습니다.

<그림 1-14>

정말 오늘 길게도 썼습니다. 씁씁후후~ 어떤 메카니즘을 가지고 동작하는지 대충 이해하셨을 듯 합니다. 그럼 다음에도 ASP.NET 4.0에 다른 기능에 대하여 알아보도록 하겠습니다.