'Microsoft'에 해당되는 글 27건

  1. 2008.10.24 ASP.NET MVC Tutorial #03
  2. 2008.10.22 Chapter 01. WCF 들어가기
  3. 2008.10.21 ASP.NET MVC Tutorial #02 1
  4. 2008.10.20 ASP.NET MVC Tutorial #01
  5. 2008.10.16 [MSDN] WCF Keyword

꾸준함에 있어서. 오늘도!

  • Creating a Tasklist Application with ASP.NET MVC
  • Understanding Models, Views, and Controllers
  • Understanding Controllers, Controller Actions, and Action Results
  • Understanding Views, View Data, and HTML Helpers
  • An Introduction to URL Routing
  • Preventing JavaScript Injection Attacks
  • Creating Unit Tests for ASP.NET MVC Applications
  • Using ASP.NET MVC with Different Versions of IIS
  • Creating Custom HTML Helpers
  • Creating Model Classes with LINQ to SQL
  • Displaying a Table of Database Data
  • Creating Page Layouts with View Master Pages
  • Passing Data to View Master Pages
  • Understanding Action Filters

  • Understanding Controllers, Controller Actions, and Action Results

     

    이 튜토리얼은 ASP.NET MVC controllers, controller actions, and action results 에 대해 알아볼 것이다. 이 튜토리얼이 끝난 후에, ASP.NET MVC 웹 사이트에서 controllers 가 방문자와 상호 작용을 통제하는 방법을 이해할 것이다.

     

    Understanding Controllers

     

    MVC controllers ASP.NET MVC 웹 사이트에 대응하는 요청에 응답할 책임을 가지고 있다. 각각의 브라우저 요청은 특별한 controller와 매핑 되어있다. 예를 들어, 브라우저 주소에 다음 URL을 넣는다고 생각하자.

     

    http://localhost/Product/Index/3

     

    이 경우, ProductController 이름의 controller가 불린다. , ProductController는 브라우저 요청에 응답한다. 이 경우, controller는 브라우저에 view을 리턴 하거나, 사용자에게 또 다른 controller을 리다이렉트 시킬 것 이다.

     

    ASP.NET MVC 어플리케이션 Controller 폴더에 새로운 controller을 만들자. Controller 이름은 접미사 Controller을 반드시 포함해야 한다. 예를 들어, ProductController는 괜찮지만 Product 라 정하면 동작하지 않을 것이다.

     



    ProductController
    라는 이름의 새로운 controller을 만들었다면 아래와 같이 코딩하자.

     

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

     

    namespace MvcApp.Controllers

    {

         public class ProductController : Controller

         {

              public ActionResult Index()

              {

                   // Add action logic here

                   throw new NotImplementedException();

              }

         }

    }

    코드를 보면, controller은 단지 클래스이고, System.Web.MVC.Controller 클래스를 상속받은 클래스이다. Controller base 클래스를 상속 받았기 때문에, controller은 부모의 메소드들을 쓸 수 있다.

     

    Understanding Controller Actions

     

    Controller controller actions에 영향을 받는다. Action은 브라우저 주소에서 특별한 URL을 입력했을 때, 불려지는 controller 메소드이다. 예를 들어, 다음 URL을 요청했다고 생각하자.

     

    http://localhost/Product/Index/3

     

    이 경우, ProductController 클래스에 있는 Index() 메소드가 불려진다. Index() 메소드는 controller action의 하나의 예 이다.

     

    Controller action controller 클래스에서 public 메소드로 정의되어야 한다. Controller 클래스에 추가된 public 메소드는 controller action에 의해 자동적으로 불려진다는 것을 명심하자.

     

    Controller action을 만족시킬 몇 가지 추가 사항이 있다. Controller action으로 사용되는 메소드는 오버로드 될 수 없다. 더욱이, controller action static 메소드가 될 수 없다.

     

    Understanding Action Result

     

    Controller action action result를 리턴 한다. Action result controller action의 브라우저 요청에 대한 응답이다.

     

    ASP.NET MVC 프레임워크는 6가지 action result 타입을 지원한다.

     

    1.     ViewResult – HTML Markup을 의미한다.

    2.     EmptyResult – 결과가 없음을 의미한다.

    3.     RedirectResult – 새로운 URL로 리다이렉트 한다는 것을 의미한다.

    4.     RedirectToRouteResult – 새로운 controller action으로 리다이렉트 한다는 것을 의미한다.

    5.     JsonResult – AJAX 어플리케이션에서 사용되는 Javascript Object Notation을 의미한다.

    6.     ContentResult – 텍스트 결과를 의미한다.

     

    모든 action result ActionResult class로부터 상속 받는다.

     

    대부분 controller action ViewResult을 리턴 한다. 예를 들어, 다음 코드 Index controller ViewResult을 리턴 한다.

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

     

    namespace MvcApp.Controllers

    {

         public class BookController : Controller

         {

              public ActionResult Index()

              {

                   return View();

              }

         }

    }

    Action ViewResult을 리턴 하면, HTML이 브라우저에 보여진다. 다시 말해, Index() 메소드는 브라우저에 Index.aspx view을 리턴 한다.

     

    위의 코드에서 Index() action은 실질적으로 ViewResult()를 리턴 하지 않는다는 것을 확인해라. Controller base 클래스의 View() 메소드가 불려진다. 일반적으로, action result 그대로를 리턴 하지 않는다. 다음 Controller base 클래스 메소드 중 하나가 불려진다.

     

    1.     View – ViewResult action result 리턴

    2.     Redirect – RedirectResult action result 리턴

    3.     RedirectToAction – RedirectToRouteResult action result 리턴

    4.     RedirectToRoute – RedirectToRouteResult action result 리턴

    5.     Json – JsonResult action result 리턴

    6.     Content – ContentResult action result 리턴

     

    그렇기 때문에, 브라우저에 View가 리턴 되기를 원한다면, View() 메소드를 호출하면 된다. 하나의 controller action에서 다른 controller action으로 리다이렉트 하길 원한다면, RedirectToAction 메소드를 호출하면 된다. 예를 들어, 다음 코드의 Details() action view을 보여주거나, Id 파라메터 값이 null 이면 Index() action을 사용자에게 리다이렉트 시킨다.

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

     

    namespace MvcApp.Controllers

    {

         public class CustomerController : Controller

         {

              public ActionResult Details(int? Id)

              {

                   if (Id == null)

                        return RedirectToAction("Index");

                   return View();

              }

     

              public ActionResult Index()

              {

                   return View();

              }

         }

    }

    ContentResult action result는 특별하다. Text action 결과를 리턴 하기 위해 ContentResult action result를 사용한다. 예를 들어, 다음 코드의 Index() 메소드는 HTML이 아닌 텍스트로서 메시지를 리턴 한다.

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

     

    namespace MvcApp.Controllers

    {

         public class StatusController : Controller

         {

              public ContentResult Index()

              {

                   return Content("Hello World!");

              }

         }

    }

    StatusController.Index() action이 불려질 때, view은 리턴 되지 않는다. 대신, “Hello World!” 가 브라우저에 출력된다.

     

    Controller action action result(Date or Integer)가 아닌 결과를 리턴 한다면, 그 결과는 자동적으로 ContentResult가 된다. 예를 들어, 다음 코드 WorkController Index() action이 불려진다면, date가 자동적으로 ContentResult로 리턴 된다.

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

     

    namespace MvcApp.Controllers

    {

         public class WorkController : Controller

         {

              public DateTime Index()

              {

                   return DateTime.Now;

              }

         }

    }

    Index() action DateTime 객체를 리턴 한다. ASP.NET MVC 프레임워크는 DateTime 객체를 string으로 변환하고, DateTime 값을 자동적으로 ContentResult로 만든다. 그래서 브라우저는 텍스트로서 날짜와 시간 값을 받는다.

     

    Summary

     

    이 튜토리얼의 목적은 ASP.NET MVC controllers, controller actions, 그리고 controller action result 의 개념을 소개하는 것이다. 첫 번째로, ASP.NET MVC 프로젝트에 어떻게 새로운 controllers을 추가하는지 설명하였고, controllerpublic 메소드가 controller action으로부터 어떻게 불려지는지를 설명했다. 마지막으로, controller action으로부터 리턴 되는 다양한 타입의 action result을 설명하였다. 특히, controller action으로 부터 ViewResult, RedirectToActionResult,, 그리고 ContentResult 가 어떻게 리턴 되는지 설명했다.

     



    Posted by glycerine
    ,

    정리 노트 랄까요.
    대단한건 아닙니다. 마치 강의 시간 필기 노트의 그것처럼.
    강의를 들으려고 Programming WCF 책을 지난 주말에 구입했습니다.
    지금부터 그 노트를 공개해볼까 합니다.


    1.     WCF 소개

    : 윈도우 기반의 서비스를 개발하고 배포하기 위한 기술.

    è  서비스 상호 작용.  커뮤니케이션 타입, 마샬링, 그리고 여러 프로토콜 관리 등을 정의하는 업계 표준의 마이크로소프트사의 구현.

    : 여러 서비스들 간의 상호 운용성 제공.

    è  호스팅, 서비스 인스턴스 관리, 비동기 호출, 신뢰도, 트랜잭션 관리, 비연결 큐 호출 기능 제공.

     

    2.     서비스

    : 외부에 노출되는 기능의 한 단위.

    미리 규약 된 통신 패턴들만 통신으로 이용.

    : 서비스와 클라이언트는 메시지(SOAP 구조)를 주고 받으며 서로 상호 작용.

        메시지? 웹 서비스와 달리 전송 프로토콜로부터 독립적.

     

    è  HTTP 뿐만 아니라 다양한 프로토콜에서도 통신 가능

    è  WCF 기반이 아닌 다른 서비스들과 통신 가능.

     

    서비스의 구성? 외부에서 보았을 때는 불투명하기 때문에 WCF 서비스는 서비스에서 사용 가능한 기능과 통신 방식을 기술하는 메타 데이터를 이용하여 노출(서비스 제공).

    -       메타 데이터는 미리 정의된 HTTP-GET 방식의 WSDL이나 메타 데이터 노출을 위해 업계 표준과 같은 기술로 배포.

     

    3.     주소 (Address)

    : 모든 서비스는 주소를 가지며, 이 주소는 서비스가 사용하고 있는 서비스 위치와 서비스의 전송 프로토콜인 전송 스키마 정보를 제공.

    : 주소 포맷

    [전송계층] : // [machine 혹은 domain] [ : 추가적인 포트] / [추가적인 URI]

    http://localhost:8000

    net.tcp://localhost:8002/MyService

    net.msmq://localhost/private/MyService

     

    읽는 방법? http://localhost:8001/MyService

    è  HTTP 전송 계층을 사용하고 있고, localhost라는 이름을 갖는 머신의 8001번 포트의 MyService가 호출을 기다리고 있다.

     

    : 지원 통신 스키마

    è  HTTP, TCP, Peer network, IPC(명명된 파이프 위의 Inter-Process 통신), MSMQ

    4.     계약 (Contract)

    : 모든 서비스는 한 개 이상의 계약을 노출한다.

      계약? 서비스가 무엇을 하는지에 대해 플랫폼 중립적이고 표준적인 방식으로 설명하는 방법

     

    종류

    è  서비스 계약 (Service Contracts)

    서비스에서 클라이언트가 어떤 동작들을 수행할 수 있는지를 설명

    è  데이터 계약 (Data Contracts)

    서비스와 주고받는 데이터 타입을 정의하는 계약

    è  오류 계약 (Fault Contracts)

    서비스로부터 어떤 에러가 발생하는지, 이 에러들을 서비스가 어떻게 처리하고 클라이언트에 전달하는지를 정의.

    è  메시지 계약 (Message Contracts)

    주고받을 메시지와 직접 상호 작용할 수 있게 해준다.

     

    서비스 계약의 정의와 구현 예제

    : ServiceContract를 사용했을 때 그 타입의 멤버를 노출하기 위해서 OperationContract를 메소드에 지정. (프로퍼티, 인덱스, 이벤트와 같은 CLR 타입에는 적용 불가)

    [ServiceContract]

    Interface IMyContract

    {

       [OperationContract]

       String MyMethod(string text);

     

       // 계약에 포함되지 않는다.

       String MyOtherMethod(string text);

    }

    Class MyService : IMyContract

    {

       Public string MyMethod(string text)

       {

          Return “Hello ” + text;

    }

    Public string MyOtherMethod(string text)

    {

       Return “Cannot call this method over WCF”;

    }

    }


    5.     호스팅

    : 모든 WCF 서비스는 호스트를 제공하는 윈도우 프로세스 안에 호스팅 되어야 한다.

     

    è  IIS 호스팅

    클라이언트의 요청으로 프로세스가 자동적으로 실행되고 호스트 프로세스의 생명 주기를 IIS에서 관리

    HTTP 전송 계층만 호스팅 가능할 수 있다는 단점.

     

    CLR 코드

    Public static void Main()

    {

       Uri tcpBaseAddress = new Uri(“net.tcp://localhost:8001/”);

       Uri httpBaseAddress = new Uri(http://localhost:8002/);

     

       ServiceHost host = new ServiceHost(typeof(MySerivce), tcpBaseAddress,

    httpBaseAddress);

    }

     

    설정파일 (Web.config App.config)

    <system.serviceModel>

       <services>

          <service name=”MyNamespace.MyService”>

             <host>

                <baseAddresses>

                   <add baseAddress=”net.tcp://localhost:8001/” />

    <add baseAddress=”http://localhost:8002/” />

    </baseAddresses>

             </host>

          </service>

       </services>

    </system.serviceModel>

     

    è  WAS 호스팅

    IIS와 달리 HTTP에 한정되지 않고 다른 여러 WCF 통신 및 포트를 사용 할 수 있다.

    (애프릴케이션 풀링, 재사용, idle time 관리, identity 관리, 분리)  

     

    6.     바인딩 (Binding)

    : 서비스는 여러 가지 관점과 많은 패턴을 가지고 있다.

    è  메시지의 경우 동기 방식의 request/reply 나 비동기 방식의 fire-and-forget 방식을 이용할 수 있고, 양방향 통신이나 여러 가지 큐 기반의 통신이 존재..

    è  HTTP, TCP, P2P, IPC, MSMQ와 같은 여러 전송 계층 이용

    è  성능을 위해 바이너리 인코딩 사용

    è  큰 용량의 데이터를 위해 MTOM 방식 사용

    위와 같은 선택들을 간단하게 하고 더 편하고 효율적으로 관리하기 위해서 바인딩 제공.

    , 전송 계층, 메시지 인코딩, 통신 패턴, 신뢰도, 보안, 전파, 상호 운용성과 같은 항목들을 조합한 설정.

     

    표준 바인딩

    è  Basic 바인딩

    BasicHttpBinding 클래스. 기본적인 ASMX 웹 서비스와 같은 WCF 서비스를 노출하도록 설계. (옛 클라이언트들이 새 서비스를 사용할 수 있도록 설계)

    è  TCP 바인딩

    NetTcpBinding 클래스. 신뢰도, 트랜잭션, 보안 제공. WCF-to-WCF 통신에 최적화.

    è  Peer network 바인딩

    NetPeerTcpBinding 클래스. Peer 네트워크가 가능한 클라이언트와 서비스들은 동일한 그리드에 접속하여 메시지를 브로드캐스팅 방식으로 전송.

    è  IPC 바인딩

    NetNamedPipeBinding 클래스. 같은 머신 안에서 명명된 파이프 계층 이용. (밖에서 호출 X, 안전한 바인딩)

    è  WS 바인딩

    WSHttpBinding 클래스. HTTP 전송 계층 사용. 신뢰도, 트랜잭션, 보안 속성 제공

    è  Federated WS 바인딩

    WSFederationHttpBinding 클래스

    è  Duplex 바인딩

    WSDualHttpBinding 클래스. 양방향 통신을 제공. WS 바인딩과 같다.

    è  MSMQ 바인딩

    NetMsmqBinding 클래스. MSMQ 전송 계층을 사용하고 비연결 기반으로 큐를 호출 하는 것을 지원.

    è  MSMQ integration 바인딩

    MsmqIntegrationBinding 클래스. WCF 메시지를 MSMQ 메시지로 변환하여 MSMQ를 사용하는 다른 환경의 시스템과 상호 운용  

     

    7.     엔드 포인트(끝점) => Address + Binding + Contract

    : 모든 서비스는 서비스의 위치를 위한 주소(Address)와 통신 방법을 정의하고 있는 바인딩(Binding), 그 서비스가 무엇을 하는지를 정의하는 계약(Contract)으로 구성. WCF는 이 셋의 관계를 엔드 포인트(끝점)라는 형식으로 표현하고 위 3가지 요소로 구성.

     

    : , 모든 엔드 포인트는 이 세가지 요소를 가지고 있어야만 하며, 호스트를 통해 노출된다. 또한, 모든 서비스는 최소한 하나의 엔드 포인트를 구성하여 노출해야 하며, 각각의 엔드 포인트는 정확한 하나의 계약을 가지고 있어야 한다.

     

    CLR 코드

    Public static void Main()

    {

       Uri tcpBaseAddress = new Uri(“net.tcp://localhost:8001/”);

       Uri httpBaseAddress = new Uri(http://localhost:8002/);

     

       Binding wsBinding = new WSHttpBinding();

       Binding tcpBinding = new NetTcpBiding();

     

       // 트랜잭션 서비스 가능하게 설정.

       tcpBinding.TransactionFlow = true;

     

       // 다중 EndPoint 설정

       ServiceHost host = new ServiceHost(typeof(MySerivce));

       host.AddServiceEndpoint(typeof(IMyContract), wsBinding, httpBaseAddress);

       host.AddServiceEndpoint(typeof(IMyContract), tcpBinding, tcpBaseAddress);

      

       host.Open();

    }

     

    설정 파일

    <system.serviceModel>

       <services>

          <service name=”MyNamespace.MyService”>

             <endpoint

                Address=”net.tcp://localhost:8000/MyService”

                BindingConfiguration=”TransactionalTCP”

                Binding=”netTcpBinding”

                Contract=”IMyContract”

             />

          </service>

       </services>

       <bindings>

          <netTcpBinding>

             <binding name=”TransactionalTCP” transactionFlow=”true” />

          </netTcpBinding>

       </bindings>

    </system.serviceModel>

     

    8.     메타 데이터의 교환

    : 서비스는 HTTP-GET 방식을 이용하거나 메타 데이터 전용으로 만든 엔드 포인트를 사용하여 메타 데이터(Metadata)를 노출. (ServiceBehavior 설정에서 enable 속성을 설정하면 HTTP-GET 방식으로 메타 데이터를 자동으로 노출.)

     

    CLR 코드

    ServiceHost host = new ServiceHost(typeof(MyService));

     

    ServiceMetadataBehavior metadataBehavior;

    metadataBehavior = host.Description.Behaviors.Find<ServiceMetadataBehavior>();

     

    if(metadataBehavior == null)

    {

       metadataBehavior = new ServiceMetadataBehavior();

       metadataBehavior.HttpGetEnabled = true;

       host.Description.Behaviors.Add(metadataBehavoir);

    }

     

    host.Open();

     

    설정 파일

    <system.serviceModel>

       <services>

          <service name=”MyService” behaviorconfiguration=”MEXGET”>

             <endpoint

                Address=”net.tcp://localhost:8000/MyService”

                BindingConfiguration=”TransactionalTCP”

                Binding=”netTcpBinding”

                Contract=”IMyContract”

             />

          </service>

       </services>

       <behaviors>

          <serviceBehaviors>

             <behavior name=”MEXGET”>

                <serviceMetadata httpGetEnabled = “true” />

             </behavior>

          </serviceBehaviors>

       </behaviors>

    </system.serviceModel>

     

    9.     클라이언트 프로그래밍

    : 클라이언트가 서비스의 동작을 호출하기 위해서 먼저 서비스 계약을 보고 해석.

    è  클라이언트가 WCF를 이용하고 있다면 일반적으로 프록시를 이용할 것

    프록시? 서비스의 계약을 나타내고 단일 CLR인터페이스를 노출하는 클라이언트의 CLR 클래스 서비스에서 여러 개의 계약들을 지원하고 있다면 클라이언트는 각각의 계약에 매칭하는 프록시를 필요로 하게 된다. 또한 서비스의 게약과 같은 동작을 제공하며 서비스를 연결하고 프록시 생명 주기를 관리하기 위한 추가적인 메소드를 추가한다.

     

    è  비주얼 스튜디오 [Add Service Reference…]

    è  SvcUtil

    SvcUtil http://localhost/MyService/MyService.scv /out:Proxy.cs

     

    10.   CLR 코드와 설정 파일

    : 이 두 가지 설정 방법은 상호 보완적이라 할 수 있다.

    è  설정 파일

    재빌드나 재배포 없이 서비스의 주요한 옵션을 변경할 수 있다.

    단 타입이 안전하지 않다는 것과 컴파일이 아닌 런타임 시에 그 에러가 발생한다는 것이 문제점.

    è  CLR 코드

    해당 설정이 특정 조건, 현재 입력 값 등과 같은 런타임 시에만 알 수 있는 것들에 의해 결정되는 경우나 해당 설정이 한 번 정해지면 절대 바뀌지 않을 경우에 유용.

     

    : CLR 코드는 동적으로 설정을 추가할 때 유용하며, 설정 파일은 정적이고 변하지 않을 경우에 유용하다. (대부분의 클라이언트와 서비스는 설정 파일을 자주 사용.) 

     

    11.   채널 설정 작업

    : 프록시 클래스를 이용하지 않고 서비스에서 동작 중인 채널들을 직접적으로 사용할 수 있다 -> ChannelFactory<T> 클래스는 필요할 때 바로 프록시를 생성하는 것이 가능

     

    ChannelFactory<IMyContract> factory = new ChannelFactory<IMyContract>();

     

    IMyContract proxy1 = factory.CreateChannel();

    Using(proxy1 as IDisposable)

    {

       Proxy1.MyMethod();

    }

     

    IMyContract proxy2 = factory.CreateChannel();

    Proxy2.MyMethod();

    ICommunicationObject channel = proxy2 as ICommunicationObject;

    Debug.Assert(channel != null);

    Channel.Close();

     

    12.   신뢰도

    : 전송 계층의 신뢰도와 메시지의 신뢰도로 구분.

    è  전송 계층의 신뢰도

    패킷의 순서 그리고 패킷이 두 지점 간에 제대로 전달된다는 것을 네트워크 패킷 수준에서 보장. (중간에 끊기면 곧바로 대응하기 힘들다)

    è  메시지 신뢰도

    메시지를 배달하는 것에 대한 보증과 메시지의 순서에 대한 보증을 제공

    연결이 끊겨 전송이 실패할 경우 다시 메시지를 전송.

    메시지 버퍼링이나 플로 제어, 폭주와 같은 것들을 자동으로 관리.

    연결을 확인하고 더 이상 필요하지 않을 경우 스스로 정리하는 등의 관리 기능 제공.

     

    바인딩 이름

    신뢰도 지원

    신뢰도

    기본지원

    메시지

    순서 보증

    메시지 순서

    기본 보증

    BasicHttpBinding

    No

    N/A

    No

    N/A

    NetTcpBinding

    Yes

    Off

    Yes

    On

    NetPeerTcpBinding

    No

    N/A

    No

    N/A

    NetNamedPipeBinding

    No

    N/A(On)

    Yes

    N/A(On)

    WSHttpBinding

    Yes

    Off

    Yes

    On

    WSFederationHttpBinding

    Yes

    Off

    Yes

    On

    WSDualHttpBinding

    Yes

    On

    Yes

    On

    NetMsmqBinding

    No

    N/A

    No

    N/A

    MsmqIntegrationBinding

    No

    N/A

    No

    N/A

     

    TCP 바인딩의 신뢰도 설정 예제

    <system.serviceModel>

       <services>

          <service name=”MyService”>

             <endpoint

                Address=”net.tcp://localhost:8000/MyService”

                Binding=”netTcpBinding”

                bindingConfiguration=”ReliableTCP”

                contract=”IMyContract”

             />

          </service>

       </services>

       <bindings>

          <netTcpBinding>

             <binding name=”ReliableTCP”>

                <reliableSession enabled=”true” />

             </binding>

          </netTcpBinding>

       </bindings>

    </system.serviceModel>

     

     

     

     

    Posted by glycerine
    ,

    #01 편도 그렇지만 포스팅하고 보니 해석이 엉망이다.
    짧은 어휘력과 의역 능력이지만 나날이 발전 하는 그날까지.

  • Creating a Tasklist Application with ASP.NET MVC
  • Understanding Models, Views, and Controllers
  • Understanding Controllers, Controller Actions, and Action Results
  • Understanding Views, View Data, and HTML Helpers
  • An Introduction to URL Routing
  • Preventing JavaScript Injection Attacks
  • Creating Unit Tests for ASP.NET MVC Applications
  • Using ASP.NET MVC with Different Versions of IIS
  • Creating Custom HTML Helpers
  • Creating Model Classes with LINQ to SQL
  • Displaying a Table of Database Data
  • Creating Page Layouts with View Master Pages
  • Passing Data to View Master Pages
  • Understanding Action Filters

  • Understanding Models, Views, and Controllers

     

    이 튜토리얼은 ASP.NET MVC Models, Views, 그리고 Controller 에 관해 자세히 알아볼 것이다. 다시 말해 ASP.NET MVC 에서 ‘M’, ‘V’ 그리고 ‘C’에 관해 설명할 것이다.

     

    이 튜토리얼을 읽은 후, ASP.NET MVC 어플리케이션의 각기 다른 영역이 어떻게 서로 돌아가는지 이해 할 것이다. ASP 어플리케이션이나 ASP.NET Web Forms 어플리케이션과 ASP.NET MVC 어플리케이션 구조가 어떻게 다른지 이해해야 한다.

     

    The Sample ASP.NET MVC Application

     

    ASP.NET MVC 웹 어플리케이션을 만듦으로써 생기는 기본 Visual Studio 템플릿은 ASP.NET MVC 어플리케이션의 각 부분을 이해하기 위한 기본적인 샘플 어플리케이션을 포함하고 있다. 우리는 이 튜토리얼에서 그 심플한 어플리케이션을 설명할 것이다.

     

    새로운 프로젝트를 만들자. (Unit Test Project No)

     

    새 프로젝트가 생성되면 솔루션 탐색기에 몇몇 폴더와 파일이 생긴 것을 볼 것이다. 중요한 것은 Models, Views, 그리고 Controllers 세 개의 폴더 이다. 폴더 이름에서 추측 할 수 있듯이, 세 폴더는 models, views, 그리고 controllers 을 설명하는 파일들을 포함한다.

     

    Controllers 폴더를 펼치면, HomeController.cs 파일을 볼 것이다. Views 폴더를 펼치면, Home Shared 이름의 서브 폴더를 볼 것이다. Home 폴더를 펼치면, About.aspx Home.aspx 파일을 볼 것이다. 이 파일들은 ASP.NET MVC 템플릿과 함께 포함된 같은 어플리케이션을 구성한다.

     


     

    현재의 프로젝트를 빌드 시켜보자. ASP.NET MVC 어플리케이션이 돌아가면, Visual Studio는 웹 브라우저에서 어플리케이션을 실행 시킨다. 샘플 어플리케이션은 Index 페이지와 About 페이지, 두 페이지로 구성된다. 어플리케이션이 처음으로 시작 될 때, Index 페이지가 나타난다.

     


    브라우저 주소 바의 URL을 자세히 보라. Home 메뉴 링크를 클릭했을 때, 브라우저 주소 바의 URL /Home으로 바뀐다. 마찬가지로 About 메뉴 링크를 클릭하면, 브라우저 주소 바의 URL /About 으로 바뀐다.

     

    브라우저를 닫고 Visual Studio로 돌아가서 Home이라는 파일과 About이라는 파일을 찾는다면 보이지 않을 것이다. 이 파일은 존재하지 않는다. 이것이 어떻게 가능한 것인가?

     

    A URL Does Not Equal a Page

     

    전통적인 ASP.NET 웹 폼 어플리케이션이나 ASP 어플리케이션을 빌드 하면, URL과 페이지가 1:1 대응된다. 서버로부터 SomePage.aspx 라는 이름의 페이지를 요청하면, SomePage.aspx 라는 이름의 페이지를 디스크에서 찾는다. SomePage.aspx 페이지가 존재하지 않는다면, 404 – Page Not Found 에러가 뜰 것이다.

     

    ASP.NET MVC 어플리케이션을 구성할 때, 대조적으로, 브라우저 주소 바에 타이핑한 URL과 어플리케이션에서 찾는 파일을 매칭시키지 않는다. ASP.NET MVC 어플리케이션에서 URL은 디스크에 존재하는 페이지가 아니라 controller action URL이 매칭된다.

     

    전통적인 ASP.NET 이나 ASP 어플리케이션에서, 브라우저 요청은 페이지에 매핑 되었다. ASP.NET MVC 어플리케이션에서는 브라우저 요청이 controller actions과 매핑 된다. ASP.NET 웹 폼 어플리케이션은 콘텐트 중심적이었다면, ASP.NET MVC 어플리케이션은 어플리케이션 논리 중심 적이다.

     

    Understanding URL Routing

     

    ASP.NET MVC 특징 중 controller action 에 매핑 된 브라우저 요청을 URL 라우팅 이라고 부른다. URL 라우팅은 controller action 에 들어오는 요청에 길을 정한다.

     

    URL 라우팅은 들어오는 요청을 다루기 위해 route table을 사용한다. route table은 웹 어플리케이션이 처음으로 시작할 때 만들어 진다. Route table Global.asax 파일에서 준비된다.

     

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

    using System.Web.Routing;

     

    namespace MvcApplication1

    {

         public class GlobalApplication : System.Web.HttpApplication

         {

              public static void RegisterRoutes(RouteCollection routes)

              {

                   routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

                   routes.MapRoute(

                   "Default",

                   "{controller}/{action}/{id}",

                   new { controller = "Home", action = "Index", id = ""}

                   );

              }

     

              protected void Application_Start()

              {

                   RegisterRoutes(RouteTable.Routes);

              }

         }

    }

     

    ASP.NET 어플리케이션이 처음 시작할 때, Application_Start() 메소드가 호출된다. 이 메소드는 RegisterRoutes() 메소드를 호출하고 RegisterRoutes() 메소드는 기본 route table을 만든다.

     

    기본 route table은 하나의 route로 구성된다. 이 기본 route은 모든 들어오는 요청을 세 조각으로 나눈다. 첫 조각은 controller 이름과 매핑되고, 두 번째 조각은 action 이름과 매핑된고, 마지막 조각은 Id 이름의 액션을 지나가는 파라미터와 매핑된다.

     

    예를 들어 다음 URL을 생각해보자.

     

    /Product/Details/3

     

    URL은 아래와 같이 3 부분으로 해석된다.

     

    Controller = ProductController

    Action = Details

    Id = 3

     

    접미사 Controller Controller 파라미터 끝에 붙는 것을 명심해라.

     

    기본 route는 기본적으로 3가지 조각들을 가지고 있다. 기본 Controller HomeController이고, 기본 Action Index, 그리고 기본 Id은 빈 문자열 값이다. 이와 같은 특징으로 다음 URL은 어떻게 해석되는지 생각해보자.

     

    /Employee

     

    URL은 아래와 같이 세 조각으로 해석된다.

     

    Controller = EmployeeController

    Action = Index

    Id = “”

     

    마지막으로 URL을 입력하지 말고 ASP.NET MVC 어플리케이션을 연다면 그때 URL은 아래와 같이 해석된다.

     

    Controller = HomeController

    Action = Index

    Id = “”

     

    이 요청은 HomeController 클래스 상에서 Index() action 이 라우트 된 것이다.

     

    Understanding Controllers

     

    Controller MVC 어플리케이션이 사용자와 상호 작용하는 방법을 통제하는 책임을 가지고 있다. Controller은 사용자가 브라우저에서 요청을 했을 때 사용자에게 무엇을 보내야 하는지 결정한다.

     

    Controller은 단지 클래스이다. 샘플 ASP.NET MVC 어플리케이션은 Controllers 폴더 안에 위치한 HomeController.cs 라는 이름의 하나의 controller을 가지고 있다.

     

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

       

    namespace MvcApplication1.Controllers

    {

         public class HomeController : Controller

         {

              public ActionResult Index()

              {

                   ViewData["Title"] = "Home Page";

                   ViewData["Message"] = "Welcome to ASP.NET MVC!";

                   return View();

              }

     

              public ActionResult About()

              {

                   ViewData["Title"] = "About Page";

                   return View();

              }

         }

    }

     

    HomeController Index() About() 두 메소드를 가지고 있는 것을 보자. 이 두 메소드는 Controller에 의해 드러나는 두 action과 일치한다. URL /Home/IndexHomeController.Index() 메소드를 불러내고, URL /Home/About HomeController.About() 메소드를 불러낸다.

     

    Controller에서 public 메소드는 controller action으로서 드러난다. 이 부분은 주의할 필요가 있다. 이것은 controller 안에 public 메소드는 브라우저에 URL을 입력하고 인터넷에 접속하는 누군가에게 불리어 질 수 있다는 것을 의미한다.

     

    Understanding View

     

    Controller HomeController 클래스에 의해 드러나고, Index() About() 메소드는 view을 리턴 한다. View은 브라우저에 보내는 HTML Markup과 콘텐트로 구성된다. View ASP.NET MVC 어플리케이션 동작에서 페이지와 동등하다.

     

    View은 올바른 위치에 만들어야 한다. HomeController.Index() action은 다음 경로에 있는 view을 리턴 한다.

    \Views\Home\Index.aspx

     

    HomeController.About() action은 다음 경로에 있는 view을 리턴 한다.

    \View\Home\About.aspx

     

    일반적으로 controller action을 위한 view가 리턴 되기를 원한다면, controller와 같은 이름의 View 폴더 안에서 서브 폴더를 만들어야 한다. 서브 폴더가 없다면, controller action을 위한 같은 이름의 aspx 파일을 만들 수 없다.

     

    <%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master"

    AutoEventWireup="true" CodeBehind="About.aspx.cs" Inherits="MvcApplication1.Views.Home.About"%>

     

    <asp:Content ID="aboutContent" ContentPlaceHolderID="MainContent" runat="server">

         <h2>About Us</h2>

         <p>

              TODO: Put <em>about</em> content here.

         </p>

    </asp:Content>

     

    View ASP 또는 ASP.NET 웹 폼의 페이지와 흡사하다. View HTML 콘텐트와 스크립트로 구성된다.

      

    Understanding Models

     

    우리는 controllers views에 관에 이야기를 했다. 마지막 주제는 models 이다. MVC model은 무엇일까?

     

    MVC model view controller에 포함되지 않는 모든 어플리케이션 로직으로 구성된다. Model은 또한 모든 비즈니스 로직과 데이터베이스 액세스 로직으로 구성되기도 한다. 예를 들어, 데이터베이스와 연결하기 위해 LINQ to SQL을 사용한다면, Models 폴더 안에 LINQ to SQL 클래스를 만들어야 한다.

     

    View은 사용자 인터페이스를 생성하는 것과 관련된 로직만으로 구성된다. Controller은 사용자에게 다른 action으로 리다이렉트 하거나 올바른 view을 리턴 하는 요청을 처리하는 최소한의 로직으로 구성된다. 이 외의 모든 것은 model 안에 포함된다.

     

    일반적으로 fat models skinny controller 만들기를 노력해야 한다. 다시 말해 controller 메소드는 적은 라인의 코드로 구성 되어야 한다. Controller action이 너무 방대해진다면, Models 폴더에 새로운 클래스를 만들어 로직을 이동시키는 것에 대해 생각해야 할 것이다.

     

    Summary

     

    이 튜토리얼은 ASP.NET MVC 웹 어플리케이션의 각기 다른 세 파트에 대해 자세히 알아 보았다. Controller actions에서 브라우저 입력 요청이 URL Routing과 어떻게 매핑 되는지 설명하였다. 또한, controllers가 어떻게 조정하고, views가 어떻게 브라우저에 리턴 하는지 설명하였다. 마지막으로, models가 어플리케이션 비즈니스와 데이터 로직을 구성하는 방법에 대해서도 설명 하였다.



    Posted by glycerine
    ,

    튜토리얼 정복 시리즈 1탄 ASP.NET MVC !!!

    Creating a Tasklist Application with ASP.NET MVC

     

    이 튜토리얼의 목적은 ASP.NET MVC 어플리케이션을 구축하는 감각을 일깨워 주는 것이다. 이 튜토리얼에서 단순한 Tasklist 어플리케이션을 구축하는 방법을 보여줄 것이다.

     

    ASP ASP.NET 에서 작업을 해봤다면, 당신은 ASP.NET MVC 가 매우 친근할 것이다. ASP.NET MVCASP 어플리케이션의 페이지와 매우 흡사하다. 그리고 전통적인 ASP.NET Web Form 어플리케이션처럼, ASP.NET MVC은 언어들과 닷넷 프레임워크에서 제공하는 클래스들에 풍부한 접근을 제공한다.

     

    The Tasklist Application

     

    단순함을 유지하기 위해, 매우 심플한 Tasklist 어플리케이션을 만들 것이다. 이 어플리케이션은 다음 3가지 기능을 가지고 있다.

     

    1.     일정의 리스트

    2.     새 일정 만들기

    3.     완료된 일정의 표시

     

    Creating an ASP.NET MVC Web Application Project

     

    Visual Studio 2008에서 새로운 ASP.NET MVC Web Application project을 만들자. File, New Project 메뉴를 선택하면 당신은 New Project dialog box가 뜨는 것을 볼 것이다. 당신의 좋아하는 프로그래밍 언어(C# or VB)를 선택하고 ASP.NET MVC Application project을 선택하자. 프로젝트 이름은 TaskList라 하고 OK 버튼을 클릭하라.

     


    (영문 VS2008에서는 unit test를 생설할지 박스가 나오는데 No 클릭)

     

    ASP.NET MVC 어플리케이션은 기본적으로 다음 폴더들을 가지고 있다. Models, Views, 그리고 Controllers 폴더 이다.

    당신은 솔루션 탐색기로 위의 폴더들을 볼 수 있다. 우리는 TaskList 어플리케이션을 구축함에 있어 Models, Views, 그리고 Controllers 폴더에 파일을 추가할 것이다.

     

    Creating the Controller

     

    보통 ASP.NET MVC 어플리케이션을 만들 때 당신은 controller을 만드는 작업부터 시작할 것이다. ASP.NET MVC 어플리케이션에 대한 각 브라우저의 요청은 controller에 의해 다뤄진다. Controller는 요청에 응답하는 어플리케이션 로직으로 구성된다.

     

    우리의 TaskList 어플리케이션에서 우리는 HomeController 클래스를 정의할 것이고 아래의 코드로 구성된다. 정의된 controller 4가지 함수를 구성한다. Index(), Create(), CreateNew(), 그리고 Complete(). 각 함수는 controller action 에 일치한다.

     

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

    using TaskList.Models;

     

    namespace TaskList.Controllers

    {

         public class HomeController : Controller

         {

              // 일정 목록을 보여준다.

              public ActionResult Index()

              {

                   return View();

              }

              // 새 일정을 작성하는 폼을 보여준다.

              public ActionResult Create()

              {

                   return View();

              }

              // 데이터베이스에 새 일정을 추가한다.

              public ActionResult CreateNew()

              {

                   return RedirectToAction("Index");

              }

              // 완료된 일정을 표시한다.

              public ActionResult Complete()

              {

                   // 데이터베이스 로직

                   return RedirectToAction("Index");

              }

         }

    }

     

    여기에 각 controller action의 목적이 있다

     

    ü  Index() – 당신이 일정의 리스트를 보기를 원할 때 호출

    ü  Create() – 당신이 새로운 일정을 추가하기 위해 등록 폼을 보기를 원할 때 호출

    ü  CreateNew() – 새로운 일정 등록을 위한 폼이 submit 되었을 때 호출. controller 행동은 실제 새로운 일정을 데이터 베이스에 추가 시키는 작업을 한다.

    ü  Complete() – 새로운 일정이 완료됨을 표시할 때 호출.

     

    우리는 추가적인 작업을 위해 controller action에 로직을 추가할 필요가 있다.

     

    Controller 클래스에 구성된 몇몇 public function controller action으로 작용한다. 이 부분은 신중히 처리해야 한다. 누구든지 그들의 웹 브라우저의 주소 바에서 올바른 URL을 통해 controller action을 호출 할 수 있다. 그렇게 때문에 당신이 호출되기를 원하지 않는 function이 있을 때 controller에서 public으로 function을 만들면 안 된다.

     

    Controller action ActionResult를 리턴 한다는 것을 명심해라. ActionResult은 해당 action이 하는 것을 의미한다. Index() Create() controller action MVC view을 리턴 한다. CreateNew() Complete() action 결과는 사용자에게 다른 controller action으로 바꿔주는 역할을 한다.

     

    controller들이 어떠한 작업을 하는지 설명하겠다. 당신이 create() controller action을 요청할 때, 새로운 일정을 만드는 폼을 구성하는 view가 리턴 된다. 당신이 이 폼에서 submit 했을 때 CreateNew() controller action이 호출된다. CreateNew() controller action은 새로운 일정을 데이터베이스에 추가하고 사용자에게 Index() controller action으로 리다이렉트한다. Index() controller action은 일정 전체 목록을 표시할 view을 리턴 한다. 마지막으로 당신이 완료 일정을 표시한다면, Complete() controller action이 호출되고 데이터베이스가 업데이트 된다. Complete() action은 사용자가에게 Index() action을 리다이렉트 하고 업데이트된 일정이 표시된다.

     

    Creating the Views

     

    View HTML markup과 브라우저로 보내는 콘텐트로 구성된다. View ASP.NET 어플리케이션에서 페이지에 가장 가까운 것이다. 당신은 확장자가 aspx인 파일을 만듦으로써 view를 만든다.

     

    당신은 올바른 위치에서 view을 구성해야 한다. 당신이 HomeController Index() action method을 위해 view를 만든다면 다음과 같은 경로 폴더 안에 view를 위치시켜야 한다.

     

    \Views\Home\Index.aspx

     

    만약 당신이 ProductController Price() action method을 위한 view을 만든다면, 다음 폴더에 위치시켜야 한다.

     

    \Views\Product\Price.aspx

     

    기본적으로 view은 그것이 일치하는 controller action 과 같은 이름을 가져야 한다. View은 항상 controller 이름과 일치하는 폴더 안에 위치해 있어야 한다.

     

    당신은 view의 서브 폴더에서 우 클릭을 통해 Add, New Item 메뉴를 선택하여 view을 만들 수 있다. View을 추가하기 위해 MVC View 페이지 템플릿을 선택해라. 우리는 다음 경로에 두 가지 view을 만들어야 한다.

     

    \Views\Home\Index.aspx

    \Views\Home\Create.aspx

     

    당신이 두 가지의 view을 만든 후, 당신의 솔루션 탐색기는 다음과 같을 것이다.

     

     



    View
    HTML content와 스크립트를 작성할 수 있다. Index.aspx view은 모든 일정의 리스트를 보여줄 것이다. View의 목적을 나타내기 위해, Index.aspx view에 다음 코드를 추가하자.

     

    <%@ Page Language="C#" AutoEventWireup="false" CodeBehind="Index.aspx.cs" Inherits="TaskList.Views.Home.Index" %>

    <!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 runat="server">

    <title></title>

    </head>

    <body>

    <div>

    <h1>My Tasks</h1>

       ... displaying all tasks

       <a href="/Home/Create">Add new Task</a>

    </div>

    </body>

    </html>

    Index.aspx view은 현재 어떠한 일정도 표시하지 않는다. 우리는 이 튜토리얼 뒤에 Index.aspx에 일정 리스트를 표시할 스크립트를 추가할 것이다.

     

    Index.aspx view Add new Task로 명명된 링크를 포함하고 있다는 것을 명심해라. 이 링크는 /Home/Create 경로로 연결되어 있다. 당신이 이 링크를 클릭할 때, HomeController 클래스의 Create() action이 불리어 진다. (invoke) Create() 메소드는 Create View를 리턴한다.

     

    Create.aspx view은 새 일정을 만드는 폼으로 구성된다. View에 다음 코드를 작성하자.

     

    <%@ Page Language="C#" AutoEventWireup="false" CodeBehind="Create.aspx.cs" Inherits="TaskList.Views.Home.Create" %>

    <!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 runat="server">

              <title></title>

         </head>

         <body>

              <div>

                   <h1>Add New Task</h1>

                   <form method="post" action="CreateNew">

                        <label for="description">Task:</label>

                        <input type="text" name="description" />

                        <br />

                        <input type="submit" value="Add Task" />

                   </form>

              </div>

         </body>

    </html>

     

    이 폼은 다음 URL 3 posts 리스트를 구성하는 것을 명심해라.

     

    /Home/CreateNew.aspx

     

    URL HomeController controller 위에 CreateNew() action에 대응한다. 새로운 일정을 나타내는 데이터 폼은 이 action에 의해 게시될 것이다.

     

    Creating the Database

     

    다음 단계로 우리의 일정을 저장할 데이터베이스를 만드는 것이다. 당신은 App_Data 폴더에서 우 클릭을 통하여, Add, New Item 메뉴를 선택하고 데이터베이스를 만들 수 있다. SQL Server 데이터베이스 템플릿 아이템을 선택하고, TaskListDB.mdf 라고 이름을 정하자.

     

    다음으로 우리는 일정을 저장할 데이터베이스 안에 테이블을 추가시켜야 한다. 솔루션 탐색기 안에 TaskListDB.mdf을 더블 클릭해라. 테이블 폴더에서 우 클릭을 하고, Add New Table 메뉴 아이템을 선택하자. 선택된 메뉴 아이템은 데이터베이스 테이블 디자이너가 열리고 다음과 같이 칼럼을 추가하자.

    Column Name

    Data Type

    Allow Nulls

    Id

    Int

    False

    Task

    Nvarchar(300)

    False

    IsCompleted

    Bit

    False

    EntryDate

    DateTime

    False

     

    첫 칼럼인 ID 칼럼은 두 가지 특별한 속성을 가지고 있다. 첫 번째로 당신은 Id 칼럼을 primary key 칼럼으로 만들어야 한다. 두 번째로 당신은 Id 칼럼을 Identity 칼럼으로 만들어야 한다.

     



    테이블이름은 Tasks 라고 하고 저장하자.

     

    (저는 SQL 상에서 데이터베이스를 만들고 서버 탐색기를 통해 연결했습니다.)

     

    Create the Model

     

    MVC Model은 당신의 어플리케이션과 데이터베이스 억세스 로직 대부분으로 구성된다. 일반적으로 당신은 Models 폴더 안에 당신의 MVC 어플리케이션이 포함된 클래스들이 놓여있다. View controller을 포함하지 않은 모든 당신의 어플리케이션 로직은 Models 폴더 안에서 밀어내야 한다.

     

    이 튜토리얼에서 우리는 전 섹션에서 만든 데이터베이스와 통신하기 위해 LINQ to SQL을 사용할 것이다. 일반적으로 나는 LINQ to SQL을 선호한다. 그러나 당신이 ASP.NET MVC 어플리케이션에서 LINQ to SQL을 사용하기를 강요하지는 않는다. 내가 언급한대로 당신은 다른 기술, 예를 들어 NHibernate 나 데이터베이스와 통신할 수 있는 프레임워크를 사용해도 된다.

     

    LINQ to SQL을 사용하기 위해 우리는 Models 폴더에 LINQ to SQL 클래스를 만들어야 한다. Models 폴더를 우 클릭하고 Add, New Item 메뉴를 선택하고, LINQ to SQL Classes 템플릿 아이템을 선택해라. 이름은 TaskList.dbml로 설정하자. 이 단계가 끝나면 Object Relational Designer가 나타날 것이다.

    우리는 Tasks 데이터베이스 테이블을 나타낼 single LINQ to SQL 엔티티 클래스를 만들어야 한다. 솔루션 탐색기에서 Tasks 테이블을 Object Relational Designer로 드래그 해라. 마지막 action Task 라는 이름의 새로운 LINQ to SQL 엔티티 클래스가 생길 것이다. 저장하자.

     


     

    Adding Database Login to the Controller Methods

     

    우리는 지금 데이터베이스를 가지고 있고, 우리의 controller action을 정의함으로써 우리는 데이터베이스에 일정을 저장할 수 있고, 검색할 수도 있다. 정의된 HomeController는 다음과 같다.

     

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

    using TaskList.Models;

     

    namespace TaskList.Controllers

    {

         public class HomeController : Controller

         {

              private TaskListDataContext db = new TaskListDataContext();

              // 일정 목록을 보여준다.

              public ActionResult Index()

              {

                   var tasks = from t in db.Tasks

                        orderby t.EntryDate

                        descending select t;

                   return View(tasks.ToList());

              }

              // 새 일정을 작성하는 폼을 보여준다.

              public ActionResult Create()

              {

                   return View();

              }

              // 데이터베이스에 새 일정을 추가한다.

              public ActionResult CreateNew(string description)

              {

                   // 데이터베이스에 새 일정 추가

                   Tasks newTask = new Tasks();

                   newTask.Task = description;

                   newTask.IsCompleted = false;

                   newTask.EntryDate = DateTime.Now;

     

                   db.Tasks.InsertOnSubmit(newTask);

                   db.SubmitChanges();

     

                   return RedirectToAction("Index");

              }

              // 완료된 일정을 표시한다.

              public ActionResult Complete(int Id)

              {

                   // 데이터베이스 로직

                   var tasks = from t in db.Tasks where t.Id == Id select t;

                   foreach (Tasks match in tasks)

                        match.IsCompleted = true;

     

                   db.SubmitChanges();

     

                   return RedirectToAction("Index");

              }

         }

    }

     

    위 코드에서 HomeController db라고 정의된 class-level private field을 가지고 있는 것을 알 수 있다. Db 필드는 TaskListDataContext 클래스의 인스턴스이다. HomeController 클래스는 TaskListDB 데이터베이스를 나타내기 위해 db 필드를 사용한다.

     

    Index() Controller action Tasks 데이터베이스 테이블로부터 모든 레코드의 검색이 정의된다. Tasks Index view를 통과한다.

     

    CreateNew() 메소드는 Tasks 데이터베이스 테이블에서 새로운 일정을 만듦을 정의한다. CreateNew() 메소드는 description으로 명명된 String 타입의 파라미터를 받는다는 것을 명심해라. 이 파라미터는 Create view를 지나가는 description 텍스트 폼 필드를 나타낸다. ASP.NET MVC 프레임워크는 자동적으로 파라미터 필드에서 controller action으로 통과된다.

     

    마지막으로 Complete() 메소드는 Tasks 데이터베이스 테이블에서 IsComplete 칼럼 값의 변화를 정의한다. 일정의 완료를 나타낼 때, task Id Complete() 메소드를 통과하여 데이터베이스를 업데이트 시킨다.

     

    Modifying the Index View

     

    Tasklist 어플리케이션을 완료하기 위한 마지막 작업이 남았다. 우리는 Index view을 수정하여 일정 목록을 나타내고 일정 완료를 표시하여야 한다. 수정된 Index view는 다음과 같다.

     

    <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Index.aspx.cs" Inherits="TaskList.Views.Home.Index" %>

    <%@ Import Namespace="TaskList.Models" %>

    <!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 runat="server">

              <title>Index</title>

         </head>

         <body>

              <div>

                   <h1>My Tasks</h1>

                   <ul>

                        <% foreach (Tasks task in (IEnumerable)ViewData.Model) { %>

                             <li>

                                  <% if (task.IsCompleted) {%>

                                       <del>

                                            <%= task.EntryDate.ToShortDateString() %>

                                            -- <%=task.Task %>

                                       </del>

                                  <% } else {%>

                                       <a href="/Home/Complete/<%= task.Id.ToString() %>">Complete</a>

                                       <%= task.EntryDate.ToShortDateString() %>

                                       -- <%=task.Task %>

                                  <% }%>

                             </li>

                        <% } %>

                   </ul>

                   <br /><br />

                   <a href="/Home/Create">Add new Task</a>

              </div>

         </body>

    </html>

     

    Index view는 모든 일정을 열거하는 C# foreach 루프를 가지고 있다. 이 일정들은 ViewData.Model 속성으로 나타낸다. 일반적으로 controller action에서 view로 데이터를 이동하기 위해 ViewData을 사용한다.

     

    루프 내에서 문법은 일정이 완료됨을 체크한다. 완료된 일정은 라인으로 보여진다. HTML <del> 태그는 완료 일정을 선으로 만들기 위해 사용된다. 일정이 완료되지 않았다면, 완료 링크 라벨은 일정의 다음을 표시한다. 링크는 다음 스크립트로 적용된다.

     

    <a href="/Home/Complete/<%= task.Id.ToString() %>">Complete</a>

     

    일정의 Id는 링크로 표현된 URL을 포함된다는 것을 명심해라. 일정 Id는 당신이 링크를 클릭했을 때 HomeController 클래스의 Complete() action을 통과한다. 이 방식으로 해당하는 데이터베이스 레코드는 당신이 완료 링크를 클릭했을 때 업데이트 된다.

     

    Index view의 마지막 버전은 다음과 같이 나타난다.

     


     

    Summary

     

    이 튜토리얼의 목적은 ASP.NET MVC 어플리케이션이 어떤 것인지를 맛보게 하는 것이다. ASP ASP.NET 어플리케이션을 만든 경험을 비추어 봤을 때 ASP.NET MVC 어플리케이션 제작이 매우 친근하다는 것을 발견했으면 하는 바램이다.

     

    이 튜토리얼에서 우리는 ASP.NET MVC 어플리케이션의 가장 기본적인 특징을 알아보았다. 앞으로의 튜토리얼에서는 우리가 controllers, controller action, views, view data 그리고 HTML Helpers 등에 대해 깊게 알아볼 것이다.

    Posted by glycerine
    ,

    [MSDN] WCF Keyword

    Microsoft/WCF 2008. 10. 16. 11:51


    용어

    정의

    계약

    (contract)

    계약은 계약의 특정 형식에 대한 지원 사양입니다. 예를 들어, 서비스 계약은 작업 그룹의 사양입니다. WCF에서 계약은 System.ServiceModel.Description 네임스페이스에 있는 설명 개체에 미러링되는 계층 구조를 가집니다. 서비스 계약은 WCF에서 가장 큰 계약 범위입니다. 서비스 계약에 있는 각 서비스 작업에는 작업에서 교환할 수 있는 메시지(오류 메시지 포함) 및 교환 방향을 지정하는 작업 계약이 포함됩니다. 작업의 각 메시지에는 메시지 계약, SOAP 메시지 봉투의 구조에 대한 사양이 포함되고, 각 메시지 계약에는 메시지에 포함된 데이터 구조를 지정하는 데이터 계약이 포함됩니다.

    구성

    (configuration)

    구성은 개발자 이외의 다른 담당자(: 네트워크 관리자)가 코드를 기록한 후 다시 컴파일 할 필요 없이 클라이언트 및 서비스 매개 변수를 설정할 수 있는 이점이 있습니다. 구성을 사용하면 끝점 주소와 같은 값을 설정할 수 있을 뿐만 아니라 끝점, 바인딩 및 동작을 추가하여 보다 세부적인 제어를 수행할 수 있습니다. 코딩이나 구성을 사용하여, 또는 두 가지를 모두 사용하여 응용 프로그램을 제어할 수 있습니다.

    끝점

    (endpoint)

    끝점은 메시지가 전송 및/또는 수신되는 구문입니다. 끝점은 메시지가 전송될 수 있는 장소를 정의하는 위치(주소), 메시지가 전송되는 방법을 설명하는 통신 메커니즘의 사양(바인딩) 및 전송될 수 있는 메시지를 설명하는 위치에서 전송 및/또는 수신될 수 있는 메시지 집합의 정의(서비스 계약)로 구성됩니다. WCF 서비스는 끝점 컬렉션으로 전역에 노출됩니다.

    데이터 계약

    (data contract)

    서비스가 사용하는 데이터 형식은 다른 서비스와 해당 서비스가 상호 운용될 수 있도록 메타데이터로 설명해야 합니다. 데이터 형식에 대한 설명을 데이터 계약이라고 하며 형식은 예를 들어 매개 변수 또는 반환 형식과 같이 메시지 일부로 사용할 수 있습니다. 서비스가 간단한 형식만 사용하는 경우 명시적으로 데이터 계약을 사용할 필요가 없습니다.

    동작

    (behavior)

    동작은 서비스, 끝점, 특정 작업 또는 클라이언트의 다양한 런타임 측면을 제어하는 구성 요소입니다. 동작은 범위에 따라 그룹화됩니다. 일반 동작은 모든 끝점에 전역적으로 영향을 주고 서비스 동작은 서비스 관련 측면에만 영향을 주며, 끝점 동작은 끝점 관련 속성에만 영향을 주고 작업 수준 동작은 특정 작업에 영향을 줍니다.

    메시지

    (message)

    메시지는 본문 및 헤더를 포함하여 여러 부분으로 구성될 수 있는 독립적인 데이터 단위입니다.

    메시지 계약

    (message contract)

    메시지 계약은 메시지 형식을 설명합니다. 예를 들어, 메시지 요소가 헤더 또는 해당 본문에 삽입되어야 할지 여부, 메시지 요소에 적용되어야 하는 보안 수준 등을 선언합니다.

    메시지 보안 모드

    (message security mode)

    메시지 보안 모드는 하나 이상의 보안 사양을 구현하여 보안을 제공하도록 지정합니다. 각 메시지에는 전송 중에 보안을 제공하고 수신자가 변조를 감지하거나 메시지를 해독하는 데 필요한 메커니즘이 포함되어 있습니다. 따라서 보안은 모든 메시지 내에 캡슐화되어 여러 홉 전반에 걸쳐 종단 간 보안을 제공합니다. 보안 정보가 메시지의 일부이기 때문에 여러 종류의 자격 증명을 메시지에 포함시킬 수도 있습니다. 이러한 자격 증명을 클레임이라고 합니다. 또한 이러한 접근 방식은 원본 및 대상 간 여러 전송을 포함하여 메시지가 전송을 통해 안전하게 전달될 수 있는 이점이 있습니다. 그러나 관련 암호화 메커니즘이 복잡하기 때문에 성능이 떨어질 수 있다는 단점이 있습니다.

    메시지 자격 증명을 사용한 전송 보안 모드

    (transport with message credential security mode)

    이 모드는 전송 계층을 사용하여 기밀성, 인증 및 메시지 무결성을 제공하는 동시에 각 메시지에는 메시지 수신자에게 필요한 여러 자격 증명(클레임)이 포함될 수 있습니다.

    메타데이터

    (metadata)

    서비스 메타데이터는 서비스와 통신하기 위해 외부 엔터티가 이해해야 하는 서비스 특성을 설명합니다. ServiceModel Metadata 유틸리티 도구(Svcutil.exe)에서 메타데이터를 사용하여 서비스와 상호 작용하는 데 클라이언트 응용 프로그램이 사용할 수 있는 WCF 클라이언트 및 관련 구성을 생성할 수 있습니다. 서비스에 의해 노출된 메타데이터에는 서비스의 데이터 계약을 정의한 XML 스키마 문서와 서비스의 메서드를 설명하는 WSDL 문서가 포함되어 있습니다. 사용할 경우 서비스와 끝점을 검사하여 WCF에 의해 서비스 메타데이터가 자동으로 생성됩니다. 서비스에서 메타데이터를 게시하려면 명시적으로 메타데이터 동작을 사용해야 합니다.

    바인딩

    (binding)

    바인딩은 끝점이 전역에서 통신하는 방법을 정의합니다. 바인딩은 통신 인프라를 만들기 위해 요소 위에 다른 요소를 "스택"하는 바인딩 요소라는 구성 요소 집합으로 구성됩니다. 최소한 바인딩은 사용할 전송(: HTTP 또는 TCP) 및 인코딩(: 텍스트 또는 이진)을 정의합니다. 바인딩은 메시지 보안을 위해 사용되는 보안 메커니즘 또는 끝점에서 사용하는 메시지 패턴과 같은 세부 사항을 지정하는 바인딩 요소를 포함할 수 있습니다.

    바인딩 요소

    (binding element)

    바인딩 요소는 전송, 인코딩, 인프라 수준 프로토콜의 구현(: WS-ReliableMessaging) 또는 통신 스택의 기타 모든 구성 요소와 같이 바인딩의 특정 부분을 나타냅니다.

    보안

    (security)

    WCF의 보안에는 기밀성(도청을 방지하기 위해 메시지 암호화), 무결성(메시지 변조를 감지하기 위한 방법), 인증(서버 및 클라이언트의 유효성 검사를 위한 방법) 및 권한 부여(리소스 액세스 권한 제어)가 포함됩니다. 이러한 기능은 HTTP를 통한 TLS(HTTPS라고도 함)와 같이 기존 보안 메커니즘을 활용하거나 다양한 WS-* 보안 사양 중 하나 이상을 구현하여 제공합니다.

    서비스

    (service)

    서비스는 하나 이상의 끝점을 노출하는 구문이며 각 끝점은 하나 이상의 서비스 작업을 노출합니다.

    서비스 계약

    (service contract)

    서비스 계약은 서로 연관된 여러 작업을 하나의 기능 단위로 묶습니다. 계약은 서비스의 네임스페이스, 해당 콜백 계약 및 기타 설정과 같은 서비스 수준 설정을 정의할 수 있습니다. 대부분의 경우 계약은 선택한 프로그래밍 언어로 인터페이스를 만들고 T:System.ServiceModel.ServiceContractAttribute 특성을 인터페이스에 적용하여 정의합니다. 실제 서비스 코드는 인터페이스를 구현한 결과입니다.

    서비스 작업

    (service operation)

    서비스 작업은 작업의 기능을 구현하는 서비스 코드에서 정의된 프로시저입니다. 이 작업은 WCF 클라이언트에서 메서드로 클라이언트에 노출됩니다. 메서드는 값을 반환하고 선택적 인수 개수를 가져오거나, 인수를 가져오지 않고 응답을 반환하지 않을 수 있습니다. 예를 들어, "Hello"로 기능하는 작업을 클라이언트의 존재에 대한 알림으로 사용하고 일련의 작업을 시작할 수 있습니다.

    시스템 제공 바인딩

    (system-provided binding)

    WCF에는 다양한 시스템 제공 바인딩이 포함되어 있습니다. 이러한 바인딩은 특정 시나리오에 맞게 최적화된 바인딩 요소의 컬렉션입니다. 예를 들어, T:System.ServiceModel.WSHttpBinding은 다양한 WS-* 사양을 구현하는 서비스와의 상호 운용성을 위해 디자인되었습니다. 이러한 바인딩은 특정 시나리오에 제대로 적용될 수 있는 옵션만 제공하기 때문에 시간이 절약됩니다. 이러한 바인딩 중 하나가 요구 사항을 충족하지 않을 경우 사용자 지정 바인딩을 만들 수 있습니다.

    시작 작업

    (initiating operation)

    새 세션의 첫 번째 작업으로 호출되는 작업입니다. 하나 이상의 작업을 호출한 후에만 시작 작업이 아닌 작업을 호출할 수 있습니다.

    오류 계약

    (fault contract)

    오류 계약은 서비스 작업과 연결하여 호출자에게 반환될 수 있는 오류를 나타낼 수 있습니다. 작업에는 작업과 관련된 오류가 0개 이상 포함될 수 있습니다. 이러한 오류는 프로그래밍 모델에서 예외로 모델링된 SOAP 오류입니다. 예외는 클라이언트에 보낼 수 있는 SOAP 오류로 변환됩니다.

    응용 프로그램 끝점

    (application endpoint)

    응용 프로그램에 의해 노출된 끝점이며 응용 프로그램이 구현하는 서비스 계약에 해당합니다.

    인스턴스 만들기 모델

    (instancing model)

    서비스에는 인스턴스 만들기 모델이 포함되어 있습니다. 인스턴스 만들기 모델에는 세 가지가 있습니다. , 단일 CLR 개체가 모든 클라이언트에 서비스를 제공하는 "단일" 모델, 각 클라이언트 호출을 처리하기 위해 새로운 CLR 개체를 만드는 "호출별" 모델 및 각 개별 세션에 대해 CLR 개체 집합을 만드는 "세션별" 모델입니다. 인스턴스 만들기 모델은 응용 프로그램 요구 사항 및 예상되는 서비스 사용 패턴에 따라 선택합니다.

    자체 호스팅 서비스

    (self-hosted service)

    자체 호스팅 서비스는 개발자가 만든 프로세스 응용 프로그램 내에서 실행되는 서비스입니다. 개발자는 수명을 제어하고 서비스 속성을 설정하며 서비스를 열고(수명 모드로 설정된 경우) 서비스를 닫습니다.

    작업 계약

    (operation contract)

    작업 계약은 매개 변수를 정의하고 작업 형식을 반환합니다. 서비스 계약을 정의하는 인터페이스를 만드는 경우 T:System.ServiceModel.OperationContractAttribute 특성을 계약의 일부인 각 메서드 정의에 적용하여 작업 계약을 나타냅니다. 작업은 단일 메시지를 가져오고 단일 메시지를 반환하거나 형식 집합을 가져오고 형식을 반환하는 방법으로 모델링할 수 있습니다. 후자의 경우 시스템에서 해당 작업에 대해 교환되는 메시지 형식을 결정합니다.

    전송 보안 모드

    (transport security mode)

    보안은 세 가지 모드 즉, 전송 모드, 메시지 보안 모드 및 메시지 자격 증명을 사용한 전송 모드 중 하나를 통해 제공할 수 있습니다. 전송 보안 모드는 전송 계층 메커니즘(: HTTPS)에 의해 제공되는 기밀성, 무결성 및 인증을 지정합니다. HTTPS와 같은 전송을 사용하면 이 모드는 성능이 효율적이며 인터넷에서 널리 사용되기 때문에 이해하기 쉽습니다. 단점은 이러한 종류의 보안이 통신 경로의 각 홉에서 개별적으로 적용되기 때문에 통신이 "메시지 가로채기(man in the middle)" 공격을 받기 쉽습니다.

    종료 작업

    (terminating operation)

    기존 세션에서 마지막 메시지로 호출되는 작업입니다. 기본적으로 WCF에서는 서비스와 연결된 세션이 닫힌 후에 서비스 개체 및 컨텍스트를 재활용합니다.

    주소

    (address)

    주소는 메시지가 수신될 위치를 지정하며, URI(Uniform Resource Identifier)로 지정됩니다. URI 스키마 부분은 HTTP TCP와 같은 주소에 도달하는 데 사용할 전송 메커니즘 이름을 지정합니다. URI의 계층적 부분에는 전송 메커니즘에 따라 다른 고유한 위치 형식이 포함됩니다. 끝점 주소를 사용하면 서비스의 각 끝점마다 고유한 끝점 주소를 만들거나 특정한 조건으로 여러 끝점 간에 주소를 공유할 수 있습니다.

    채널

    (channel)

    채널은 바인딩 요소의 구체적인 구현입니다. 바인딩은 구성을 나타내고 채널은 해당 구성과 관련된 구현입니다. 따라서 각 바인딩 요소마다 관련된 채널이 있습니다. 채널은 다른 채널 맨 위에 스택되어 바인딩의 구체적인 구현인 채널 스택을 만듭니다.

    코딩

    (coding)

    개발자가 서비스 또는 클라이언트의 모든 구성 요소에 대해 엄격한 제어를 유지할 수 있도록 하며, 구성을 통해 수행된 모든 설정을 검사하고 필요한 경우 코드를 통해 재지정할 수 있습니다. 코딩이나 구성을 사용하여, 또는 두 가지를 모두 사용하여 응용 프로그램을 제어할 수 있습니다.

    클라이언트 응용 프로그램

    (client application)

    클라이언트 응용 프로그램은 메시지를 하나 이상의 끝점과 교환하는 프로그램입니다. 클라이언트 응용 프로그램은 WCF 클라이언트의 인스턴스를 만들고 WCF 클라이언트의 메서드를 호출하여 시작합니다. 하나의 응용 프로그램이 클라이언트 및 서비스 역할을 모두 수행할 수 있다는 점에 주의하십시오.

    호스팅

    (hosting)

    일부 프로세스의 경우 서비스를 호스팅해야 합니다. 호스트는 서비스 수명을 제어하는 응용 프로그램입니다. 서비스는 기존 호스팅 프로세스에 의해 자체 호스팅되거나 관리될 수 있습니다.

    호스팅 프로세스

    (hosting process)

    호스팅 프로세스는 서비스를 호스팅하기 위해 디자인된 응용 프로그램입니다. 여기에는 IIS(인터넷 정보 서비스), WAS(Windows Activation Services) Windows Services가 있습니다. 이러한 호스팅된 시나리오에서 호스트는 서비스 수명을 제어합니다. 예를 들어, IIS를 사용하는 경우 서비스 어셈블리 및 구성 파일이 포함된 가상 디렉터리를 설정할 수 있습니다. 메시지를 수신하면 IIS는 서비스를 시작하고 수명을 제어합니다.

    WCF 클라이언트

    (WCF client)

    WCF 클라이언트는 서비스 작업을 메서드로(Visual Basic 또는 Visual C#과 같이 선택한 .NET Framework 프로그래밍 언어로 표시) 노출하는 클라이언트 응용 프로그램 구문입니다. 모든 응용 프로그램은 서비스를 호스팅하는 응용 프로그램을 포함하여 WCF 클라이언트를 호스팅할 수 있습니다. 따라서 다른 서비스의 WCF 클라이언트를 포함하는 서비스를 만들 수 있습니다. WCF 클라이언트는 ServiceModel Metadata 유틸리티 도구(Svcutil.exe)를 사용하고 메타데이터를 게시하는 실행 중인 서비스에서 선택하여 자동으로 만들 수 있습니다.

    WS-*

    WS-Security, WS-ReliableMessaging 등과 같이 WCF에서 구현되고 계속 업데이트되는 WS(웹 서비스) 사양 집합의 약어입니다.


     

    Posted by glycerine
    ,