'Microsoft'에 해당되는 글 27건

  1. 2008.12.01 ASP.NET MVC Tutorial #05
  2. 2008.11.27 ASP.NET MVC Tutorial #04
  3. 2008.11.25 All About LINQ Site
  4. 2008.11.19 Business Data Catalog
  5. 2008.10.24 Chapter 02. 서비스 계약 1

ASP.NET MVC Tutorial #05

Microsoft/ASP.NET MVC 2008. 12. 1. 17:43

  • 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


    An Introduction to URL Routing

     

    이 튜토리얼에서, URL Routing이라 불리는 ASP.NET MVC 어플리케이션이 중요한 특징에 관해 설명할 것입니다. URL Routing 모듈은 특정 MVC controller actions에 대한 브라우저 요청을 매핑 합니다.

     

    이 튜토리얼 처음에, 표준 route table이 어떻게 controller actions에 요청을 매핑 하는지 배울 것 입니다. 두 번째로, 기본 route table을 어떻게 수정하고 적용하는지 배울 것 입니다.

     

    Using the Default Route Table

     

    새로운 ASP.NET MVC 어플리케이션을 만들면, 어플리케이션은 이미 URL Routing을 사용할 준비를 해놓습니다. URL Routing은 두 단계 준비작업이 있습니다.

     

    첫 번째로, URL Routing은 어플리케이션의 웹 구성 파일(Web.config file)에 활성화 됩니다. 구성 파일에는 routing에 상응하는 4가지 영역이 있습니다. system.web.httpModules 영역, system.web.httpHandlers 영역, system.webserver.modules 영역, 그리고 system.webserver.handlers 영역이 해당되는데 이 영역이 없으면 동작을 안 하기에 삭제에 신중해야 합니다.

     

    두 번째로, 중요한 부분으로서, route table은 어플리케이션의 Global.asax 파일에 생성됩니다. 이 파일은 ASP.NET 어플리케이션 생명주기 이벤트와 관련된 이벤트 핸들러로 구성된 특별한 파일입니다. Route table은 어플리케이션 시작 이벤트가 발생할 때 만들어 집니다.

     

    다음 코드는 ASP.NET MVC 어플리케이션에 포함된 기본 Global.asax 입니다.

     

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

    using System.Web.Routing;

     

    namespace MyApp

    {

         public class GlobalApplication : System.Web.HttpApplication

         {

              public static void RegisterRoutes(RouteCollection routes)

              {

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

                   routes.MapRoute(

                        "Default", // Route name

                        "{controller}/{action}/{id}", // URL with parameters

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

                        // Parameter defaults );

              }

     

              protected void Application_Start()

              {

                   RegisterRoutes(RouteTable.Routes);

              }

         }

    }

     

    ASP.NET MVC 어플리케이션이 처음 시작할 때, Application_Start() 메소드가 실행됩니다. 이 메소드는, RegisterRoutes() 메소드를 호출하고, RegisterRoutes() 메소드가 route table을 생성합니다.

     

    기본 route table은 Default라는 이름의 single route 로 구성됩니다. Default route은 URL의 첫 번째 구분을 controller name과 매핑 시키고, 두 번째 구분을 URL의 controller action과 매핑 시킵니다. 그리고 세 번째 구분을 id 라는 파라메터로 매핑 시킵니다.

     

    웹 브라우저 주소 바에 다음 URL의 입력을 생각해보세요.

    /Home/Index/3

     

    Default route은 다음 파라메터들로 매핑 시킵니다.

    Controller = Home

    Action = Index

    Id = 3

     

    URL /Home/Index/3을 요청할 때, 다음 코드가 실행됩니다.

    HomeController.Index(3)

     

    Default route은 3가지 파라메터는 기본값을 가지고 있습니다. Controller가 빠졌다면 controller 파라메터의 기본값인 Home이 적용됩니다. Action이 빠졌다면, action 파라메터의 기본값인 Index가 적용됩니다. 마지막으로 id 파라메터가 빠졌다면, 기본값인 공백 string이 적용됩니다.

     

    아래의 URL을 브라우저 주소 창에 입력하면 Default route가 controller actions에 어떻게 매핑 시킬지 생각해보세요.

    /Home

     

    Default route 파라메터가 기본값으로 설정하여, 아래 코드의 HomeController 클래스의 Index() 메소드가 실행될 것입니다.

     

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

     

    namespace MyApp.Controllers

    {

         [HandleError]

         public class HomeController : Controller

         {

              public ActionResult Index(string Id)

              {

                   return View();

              }

         }

    }

     

    위 코드에서, HomeController 클래스는 Id라는 단일 파라메터를 받는 Index() 메소드를 포함하고 있습니다. URL /Home은 id 파라메터를 공백으로 Index() 메소드를 호출할 것입니다.

     

    ASP.NET MVC 프레임워크는 controller actions을 호출 하기 때문에, URL /Home은 아래 코드의 HomeController 클래스에 있는 Index() 메소드와 매치 시킵니다.

     

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

     

    namespace MyApp.Controllers

    {

         [HandleError]

         public class HomeController : Controller

         {

              public ActionResult Index()

              {

                   return View();

              }

         }

    }

     

    위의 Index() 메소드는 어떠한 파라메터도 받지 않습니다. URL /Home이 호출될 때, Index() 메소드를 부릅니다. URL /Home/Index/3 이 입력된다면 아이디를 무시하고 이 메소드가 불려질 것입니다.

     

    URL /Home은 항상 다음 코드의 HomeController 클래스 내의 Index() 메소드로 처리될 것입니다.

     

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

     

    namespace MyApp.Controllers

    {

         [HandleError]

         public class HomeController : Controller

         {

              public ActionResult Index(int? id)

              {

                   return View();

              }

         }

    }

     

    위 코드에서, Index() 메소드는 하나의 정수형 파라메터를 가지고 있습니다. 파라메터가 nullable 파라메터이기 때문에, Index() 메소드는 에러 발생 없이 호출될 것입니다.

     

    마지막으로, 다음 코드에서 URL /Home으로 인하여 Index() 메소드가 불려지면, Id Parameter가 nullable 파라메터가 아니라는 에러가 발생됩니다.

     

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

     

    namespace MyApp.Controllers

    {

         [HandleError]

         public class HomeController : Controller

         {

              public ActionResult Index(int id)

              {

                   return View();

              }

         }

    }

      

    한편으로, URL /Home/Index/3은 위 코드에서 잘 작동합니다. 3은 파라메터 값으로 전달되어 Index() 메소드가 호출 될 것입니다.

     

    Creating a Custom Route

     

    ASP.NET MVC 어플리케이션을 위해, 기본 route table은 잘 작동 할 것입니다. 하지만, 특별한 routing에 대한 요구에 대하여 custom route을 만들 수도 있습니다.

     

    예를 들어 블로그 어플리케이션을 만든다고 가정합시다. 아래와 같은 요청을 처리 해봅시다.

    /Archive/12-25-2009

     

    사용자가 이와 같은 요청을 했을 때, 12/25/2009 에 응답하는 블로그를 원합니다. 이런 유형의 요청을 다루기 위해서, custom route을 만들 필요가 있습니다.

     

    아래의 Global.asax 파일은 /Archive/entry date 와 같은 요청을 다루는 Blog라는 이름의 새로운 custom route을 가지고 있습니다.

     

    using System.Web.Mvc;

    using System.Web.Routing;

     

    namespace MyApp

    {

         public class GlobalApplication : System.Web.HttpApplication

         {

              public static void RegisterRoutes(RouteCollection routes)

              {

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

                   routes.MapRoute(

                        "blog",

                        "Archive/{entryDate}",

                        new {controller = "Archive", action = "Entry"}

                        );

                   routes.MapRoute(

                        "Default", // Route name

                        "{controller}/{action}/{id}", // URL with parameters

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

                        // Parameter defaults );

              }

     

              protected void Application_Start()

              {

                   RegisterRoutes(RouteTable.Routes);

              }

         }

    }

     

    Route table에 추가한 route의 순서는 매우 중요합니다. Blog라는 새로운 custom route은 Default route 전에 추가 해야 합니다. 순서가 바뀐다면, Default route은 항상 custom route 대신 호출될 것입니다.

     

    Custom Blog route은 다음과 같은 /Archive 로 시작하는 요청을 처리 할 것입니다.

    /Archive/12-25/2009

    /Archive/10-6-2004

    /Archive/apple

     

    Custom route은 Archive controller와 Entry() action에 매핑 될 것입니다. Entry() 메소드가 호출되면, entryDate 파라메터로 전달될 것입니다.

     

    Blog custom route을 다음 코드의 controller 로 사용할 수 있습니다.

     

    using System;

    using System.Web.Mvc;

     

    namespace MyApp.Controllers

    {

         public class ArchiveController : Controller

         {

              public string Entry(DateTime entryDate)

              {

                   return "You requested the entry on " + entryDate.ToString();

              }

         }

    }

     

    위 코드에서 Entry() 메소드는 DateTime 타입의 파라메터를 받는다는 것을 확인하세요. ASP.NET MVC 프레임워크는 자동적으로 URL의 날짜를 DateTime 타입으로 변환해줍니다. URL에 날짜 입력 값이 DateTime으로 변환될 수 없다면, 에러가 발생됩니다.


    [ASP.NETMVC]05.AnIntroductiontoURLRouting.docx

    • 저작자표시
    Posted by glycerine
    ,

    ASP.NET MVC Tutorial #04

    Microsoft/ASP.NET MVC 2008. 11. 27. 14:19

  • 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 Views, View Data, and HTML Helpers

     

    이 튜토리얼의 목적은 ASP.NET MVC views, view data, 그리고 HTML Helpers 에 관한 설명을 할 것이다. 이 튜토리얼의 마지막에서, 새로운 views을 어떻게 만들고, controller에서 view로 데이터가 어떻게 이동하는지, 그리고 view에서 콘텐트를 가져오기 위해 HTML Helpers가 어떻게 사용되는지 이해할 수 있을 것이다.

     

    Understanding Views

     

    ASP.NET 이나 ASP와는 달리, ASP.NET MVC은 URL에 해당되는 페이지를 포함하지 않는다. ASP.NET 어플리케이션에서, 사용자가 브라우저 주소 바에 입력한 URL 경로에 대응하는 것은 디스크에 존재하는 페이지가 아니다. ASP.NET MVC 어플리케이션에서 페이지에 가장 가까운 것은 view 이다.

     

    ASP.NET MVC 어플리케이션에서, 브라우저 입력 요청은 controller action과 매핑 된다. Controller action은 view을 리턴 한다. 그러나, controller action은 다른 controller action에 리다이렉트 하는 것처럼 다른 형태의 action을 취할 때도 있다.

     

    다음 코드는 HomeController라는 간단한 controller이다. HomeController은 Index()와 Details()라는 두 개의 controller action을 나타낸다.

     

    using System;

    using System.Collections.Generic;

    using System.Linq;

    using System.Web;

    using System.Web.Mvc;

     

    namespace MvcApp.Controllers

    {

         [HandleError]

         public class HomeController : Controller

         {

              public ActionResult Index()

              {

                   return View();

              }

     

              public ActionResult Details()

              {

                   return RedirectToAction("Index");

              }

         }

    }

     

    브라우저 주소 바에 다음과 같은 URL을 입력하면, 첫 action으로 Index()가 불린다.

    /Home/Index

     

    브라우저 주소 바에 다음 URL을 입력하면, 두 번째 action으로 Detail()가 불린다.

    /Home/Details

     

    Index() action은 view을 리턴 한다. 사용자들이 만든 대부분의 action은 view을 리턴 한다. 그러나, action은 다른 형태의 결과를 리턴 하기도 하는데, 예를 들어, Details() action은 Index() action은 입력 요청을 Index() action으로 리다이렉트 하는 RedirectToActionResult을 리턴 한다.

     

    Index() action은 다음 코드를 가지고 있다.

     

    return View();

     

    이 코드는 웹 서버에 다음 경로의 위치한 view을 리턴 한다.

    \Views\Home\Index.aspx

     

    View의 경로는 controller의 이름과 controller action의 이름으로 생각해 볼 수 있다.

     

    마찬가지로 생각해 본다면, 다음 코드는 “Fred”라는 이름의 view을 리턴 할 것이다.

     

    return View(“Fred”);

     

    이 코드가 실행될 때, view은 다음 경로를 리턴 할 것이다.

    \Views\Home\Fred.aspx

     

    Creating a View

     

    View을 추가 할 때는, Controller 접미사를 제외한 controller와 같은 이름을 가진 폴더에 생성해야 한다. 예를 들어, ProductController라는 이름의 controller에 의해 리턴 되는 Index view을 만든다면, 프로젝트에서 다음 경로로 추가 시켜야 한다.

    \Views\Product\Index.aspx

     

    View을 가진 폴더 이름은 반드시 view을 리턴 하는 controller 이름과 일치하여야 한다.

     

    Adding Content to a View

     

    View은 스크립트를 포함할 수 있는 표준 HTML 문서이다. View에 동적 콘텐트를 위해 스크립트를 추가할 수 있다. 예를 들어 다음 코드의 view은 현재 날짜와 시간을 표시한다.

     

    <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Index.aspx.cs"

     Inherits="MvcApp.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>Index</title>

         </head>

         <body>

              <div>

                   The current date and time is:

                   <% Response.Write(DateTime.Now);%>

              </div>

         </body>

    </html>

     

    위 코드의 HTML의 body은 다음 스크립트를 가지고 있다.

     

    <% Response.Write(DateTime.Now);%>

     

    당신은 스크립트 시작과 끝에 나타낼 스크립트 구획 문자로 <% 과 %>을 사용한다. 이 스크립트는 C# 코드이고, 브라우저가 콘텐트를 렌더링 할 때 Response.Write()을 호출 함으로써 시간과 날짜를 표시한다.

     

    Response.Write()을 자주 호출 하기에 마이크로소프트는 Response.Write() 메서드를 호출하기 위한 쉬운 방법을 제공한다. 다음 코드의 view에서 Response.Write() 호출을 간단히 하기 위해 구획 문자 <%= 와 %>을 사용한다.

     

    <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Index2.aspx.cs"

     Inherits="MvcApp.Views.Home.Index2" %>

    <!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>Index2</title>

         </head>

         <body>

              <div>

                   The current date and time is:

                   <%=DateTime.Now%>

              </div>

         </body>

    </html>

     

    view에서 동적 콘텐트를 가져오기 위해 .NET 언어를 사용 할 수 있다. 일반적으로 Visual Basic .NET 이나 C#을 사용할 것이다.

     

    Using HTML Helpers to Generate View Content

     

    View에 콘텐트를 쉽게 추가할 수 있게, HTML Helper라 불리는 유용한 메소드를 사용할 수 있다. HTML Helper은 문자열을 가져오는 메소드이다. 예를 들어, textboxes, links, dropdown, 그리고 list boxes등과 같은 HTML 요소들을 사용하는 HTML Helper를 이용한다.

     

    예를 들어, 다음 코드에서 view은 로그인 폼을 만들기 위하여 TextBox() 와 Password() Helper을 사용한다.

     

    <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Index3.aspx.cs"

     Inherits="MvcApp.Views.Home.Index3" %>

    <!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>Login Form</title>

         </head>

         <body>

              <div>

                   <form method="post" action="/Home/Login">

                        <label for="userName">User Name:</label>

                        <br />

                        <%=Html.TextBox("userName")%>

                        <br /><br />

                        <label for="password">Password:</label>

                        <br />

                        <%=Html.Password("password")%>

                        <br /><br />

                        <input type="submit" value="Log In" />

                   </form>

              </div>

         </body>

    </html>

     

     

    모든 Html Helper 메소드는 view의 HTML 프로퍼티라 불린다. 예를 들어, Html.TextBox() 메소드를 호출 함으로써 TextBox 을 그린다.

     

    HTML Helper을 호출할 때, 스크립트 구분 문자 <%= %>을 사용한다는 것을 알아두자. HTML Helper은 간단하게 문자열을 리턴 한다. 브라우저에 문자열을 그리기 위하여 Response.Write() 호출을 통해야 한다.

     

    HTML Helper 메소드를 사용하는 것은 선택적이다. 하지만 이것을 사용함으로 작성해야 할 HTML과 스크립트 코드의 양을 줄일 수 있다. 다음 코드에서 view은 HTML Helpers을 사용하지 않고 위 코드의 view와 같은 폼을 브라우저에 표현한다.

     

    <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Index4.aspx.cs"

     Inherits="MvcApp.Views.Home.Index4" %>

    <!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>Login Form without Help</title>

         </head>

         <body>

              <div>

                   <form method="post" action="/Home/Login">

                        <label for="userName">User Name:</label>

                        <br />

                        <input name="userName" />

                        <br /><br />

                        <label for="password">Password:</label>

                        <br />

                        <input name="password" type="password" />

                        <br /><br />

                        <input type="submit" value="Log In" />

                   </form>

              </div>

         </body>

    </html>

     

    다시 말하자면, HTML Helpers 작성은 선택적이다. 예를 들어, 자동적으로 HTML 테이블에 데이터베이스 레코드 집합을 보여주기 위한 GridView() 메소드를 만들 수 있다. 지금까지 Creating Custom HTML Helper를 주제로 이야기를 하였다.

     

    Using View Data to Pass Data to a View

     

    View는 ViewData라는 controller에서 view로 데이터를 전달하는 속성을 가지고 있다. 예를 들어, 다음 코드의 controller은 ViewData 에 메시지를 추가하는 코드이다.

     

    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 Details()

              {

                   ViewData["message"] = "Hello World!";

                   return View();

              }

         }

    }

     

    ViewData controller 프로퍼티는 이름과 값으로 구성된 콜렉션을 나타낸다. 위 코드에서, Detail() 메소드는 “Hello World!” 라는 값을 가진 message라는 이름의 view data 콜렉션에 아이템을 추가한다. View가 Details() 메소드에 의해 리턴 되면, view data는 자동적으로 view에 전달된다.

     

    아래의 코드에서 view은 view data로부터 message을 받고, 브라우저의 값을 렌더링 한다.

     

    <%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Details.aspx.cs"

       Inherits="MvcApp.Views.Product.Details" %>

    <!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>Product Details</title>

         </head>

         <body>

              <div>

                   <%=Html.Encode(ViewData["message"])%>

              </div>

         </body>

    </html>

     

    view에서 메시지가 렌더링 될 때, Html.Encode() HTML Helper 메소드가 갖는 이점이 있다. Html.Encode() HTML Helper은 특별한 문자, 예를 들어 웹 페이지에서 보여지는 안전한 문자로 인코딩한다. 당신이 사용자가 웹 사이트로 submit한 콘텐트를 렌더링 할 때 마다, 자바스크립트 인젝션 공격을 보호하기 위해 콘텐트를 인코딩 해야 한다.

     

    위 코드에서 controller에서 view로 간단한 문자 메시지를 전송하는 view data을 보았다. 당신은 예를 들어, 데이터베이스 레코드 콜렉션처럼 여러 타입의 데이터를 전송하는 view data을 사용할 수 있다. View에 Product 데이터베이스 테이블의 콘텐트를 보여주기를 원한다면, view data로 데이터베이스 레코드 콜렉션을 전송해야 한다.

     

    [ASP.NETMVC]04.UnderstandingViews,ViewData,andHTMLHelpers.docx

    • 저작자표시
    Posted by glycerine
    ,

    All About LINQ Site

    Microsoft/Linq 2008. 11. 25. 14:15

    지난 토요일 MVP 김수영님의 재직자 Linq 강좌를 듣고 관심이 부쩍 늘었네요.
    쿼리식의 그 편리함. 성능 이슈는 둘째 치고 편리함에 빠져드네요.

    강좌를 정리해서 올리기 전에 Linq 관련 사이트들을 꾸준히 업데이트 해볼까 합니다.



    MSDN C# 프로그래밍 가이드
    http://msdn.microsoft.com/ko-kr/library/bb397676.aspx

    MSDN The LINQ Project
    http://msdn.microsoft.com/en-us/vcsharp/aa904594.aspx

    MSDN 101 LINQ Samples
    http://msdn.microsoft.com/en-us/vcsharp/aa336746.aspx

    ASP.NET Video
    http://www.asp.net/learn/linq-videos/

    LINQ Pad
    http://linqpad.net/



    저작자표시
    Posted by glycerine
    ,

    Business Data Catalog

    Microsoft/SharePoint Server 2008. 11. 19. 14:56

    BDC 자료 찾으려고 구글링 중 MSDN 링크을 알차게 모은 블로그 발견!

    덧. 작심 삼일도 이런건 없네요. MVC 칼럼 3개. 낼 사내 발표 멋지게 끝내고 와서 다시 열심히 달리겠스니다. :)

    -------------------------------------------------------------------------------------------------------

    Business Data Catalog, a new feature introduced in Microsoft Office SharePoint Server 2007, provides an easy way to integrate business data from back-end server applications, such as SAP or Siebel, within Office SharePoint Server 2007 without writing any code. This section contains overview information and step-by-step, how-to procedures for programming with the Business Data Catalog.

     

    In This Section

    Business Data Catalog: Overview

    Learn about this new business integration feature that enables Office SharePoint Server 2007 to surface business data from back-end server applications without any coding.

    Business Data Catalog: Architecture

    Business Data Catalog comprises a metadata repository and an object model that provide a unified and simple way to invoke operations and a consistent, object-oriented programming interface for business logic that lives in the various business applications.

    Business Data Catalog: Roles and Development Life Cycle

    Four roles—business analyst, metadata author, administrator, and developer—are necessary to create and deploy business data solutions in an Office SharePoint Server 2007 environment.

    Business Data Catalog: Development Scenarios

    Review development scenarios for authoring metadata and building custom applications with Business Data Catalog.

    Business Data Catalog: Metadata Model

    Learn how Business Data Catalog provides homogeneous access to the underlying data sources with a declarative metadata model that provides a consistent and simplified client object model.

    Authoring Metadata

    Find detailed, step-by-step procedures for authoring metadata for business applications to work with Business Data Catalog.

    Building Custom Applications Using the Business Data Catalog

    Get how-to information and code examples for building custom applications with Business Data Catalog.

    Business Data Catalog: Security Model

    Learn about the Business Data Catalog authentication and authorization model.

    Troubleshooting Business Data Clients and Metadata

    Find tips for easy debugging and troubleshooting of metadata-related errors and run-time exceptions.

    FAQ: Business Data Catalog

    Find tips and answers to frequently asked questions.

    Business Data Catalog: Glossary

    Get definitions of terms commonly used with Business Data Catalog.

    Reference

    Microsoft.Office.Server.ApplicationRegistry.MetadataModel
    Microsoft.Office.Server.ApplicationRegistry.Runtime
    Microsoft.Office.Server.ApplicationRegistry.Administration
    Microsoft.Office.Server.ApplicationRegistry.Infrastructure
    Microsoft.Office.Server.ApplicationRegistry.SystemSpecific.Db
    Microsoft.Office.Server.ApplicationRegistry.SystemSpecific.WebService

    Related Sections

    What's New for Developers in Office SharePoint Server 2007

    Find summary descriptions of Business Data Catalog, single sign-on, and all other new and enhanced features of Office SharePoint Server 2007.

    Single Sign-on

    Learn how to implement a new pluggable single sign-on mechanism that allows you to use alternate single sign-on providers.

    READ MORE here: http://msdn2.microsoft.com/en-us/library/ms563661....

    저작자표시
    Posted by glycerine
    ,

    Chapter 02. 서비스 계약

    Microsoft/WCF 2008. 10. 24. 14:38

    책을 보며 느낀것 이지만 이번 챕터는 WCF 만 제한된 내용은 아닙니다.
    아키텍처가 되자. 라는 얘기가 생각나네요.


    개요

    인터페이스(또는 클래스)를 서비스 지향적인 계약으로 노출

    è  언어의 인터페이스 등의 기능을 이용해 프로그래밍: WCF 서비스와 계약으로 제공

     

    1.     Operation 오버로딩

     

    Interface ICalculator

    {

       Int Add(int arg1, int arg2);

       Double Add(double arg1, double arg2);

    }

     

    C++이나 C# 등의 프로그래밍 언어는 이름은 같지만 파라미터의 타입이나 수가 다른 메서드의 오버로딩을 지원하고 있다. 중요한 건 Operation 오버로딩은 개념상 WSDL 기반의 동작에서는 동작할 수 없다는 것이다. 따라서 다음과 같은 계약은 컴파일이 가능하지만 서비스 호스트 로드 시 Invalid operationException 예외를 발생시킨다.

     

    하지만 수동으로 Operation 오버로딩을 가능하게 설정할 수 있다. 그 방법은 OperationContract 애트리뷰트의 Name 속성을 이용하여 Operation의 가칭을 지어 주는 것이다.

     

    [ServiceContract]

    Interface ICalculator

    {

       [OperationContract(Name = “AddInt”)]

       Int Add(int arg1, int args2);

      

       [OperationContract(Name = “AddDouble”)]

       Double Add(double arg1, double arg2);

    }

     

    클라이언트에서도 참조한 계약의 Name 프로퍼티를 이용하여 참조된 Opetion과 동일한 이름의 가칭(별칭)을 주어 메서드를 오버로딩 할 수 있다.

     

    [ServiceContract]

    Public interface ICalculator

    {

       [OperationContract(Name = “AddInt”)]

       Int Add(int arg1, int arg2);

     

       [OperationContract(Name = “AddDouble”)]

       Double Add(double arg1, double arg2);

    }

     

    Public partial class CalculatorClient : ClientBase<ICalculator>, ICalculator

    {

       Public int Add(int arg1, int arg2)

       {

          Return Cahnnel.Add(arg1, arg2);

       }

     

       Public double Add(double arg1, double arg2)

       {

          Return Channel.Add(arg1, arg2);

       }

    }

     

    이렇게 하여 클라이언트는 Operation 오버로딩을 통하여 읽기 쉽고 자연스러운 프로그래밍 모델로 구현할 수 있다.

     

    CalculatorClient proxy = new CalculatorClient();

     

    Int result1 = proxy.Add(1, 2);

    Double result2 = proxy.Add(1.0, 2.0);

     

    Proxy.Close();

     

    2.     계약의 상속

     

    서비스 계약의 인터페이스는 각각 파생할 수 있고, 계약의 계층으로 정의하여 이용할 수 있지만, ServiceContract 애트리뷰트는 상속이 불가능하다. 따라서 인터페이스의 모든 계층은 명백한 ServiceContract 애트리뷰트를 가지고 있어야 한다.

     

    호스트는 최종적으로 상속받은 인터페이스로 하나의 엔드 포인트를 노출시킬 수 있다.

     

    <service name = “MyCalculator”>

       <endpoint

          Address = http://localhost:8001/MyCalculator/

          Binding = “basicHttpBinding”

          Contract = “IScientificCalculator”

       />

    </service>

     

    인터페이스를 상속하여 정의된 서비스 엔드 포인트의 메타 데이터를 클라이언트가 참조하게 되면 클라이언트의 계약은 상속 계층을 유지하지 않고, 하나의 계약 안에 포함되어 구성한다. 즉, 그 계약은 기존의 인터페이스들에서 가졌던 모든 Operation이 하나의 계약으로 조합된다. 또한 참조된 계약의 모든 메서드는 하나의 프록시를 통해 구현된다.

     

    추가사항: 클라이언트에서 상속의 재구성

     

    3.     서비스 계약의 설계 및 팩토링

     

    서비스 계약에 대한 디자인을 어떻게 할 것인가?

    어느 계약에 어느 동작들을 포함시킬 것인가?

    서비스 계약에는 얼마나 많은 동작들을 가지는 것이 좋은가?

    è  서비스 지향적 분석 및 설계

     

    WCF 에서 만의 내용이 아닌 객체지향 프로그램으로 생각하자. 서비스 계약을 분해할 때 언제나 재사용적인 관점들을 생각해야 한다.

     

    간단한 예를 통해 생각해보자.

    강아지 서비스 모델을 만들고 싶다고 가정해보자. 이 서비스의 요구 사항을 살펴보면 강아지는 짖을 수 있거나 물어 오기 놀이를 할 수 있다. 또한 가출병원의 등록 번호를 가지고 있고 백신 접종도 할 수 있을 것이다. 즉, IDog 서비스 계약을 정의할 수 있고 PoodleService, GermanShepherdService와 같은 서비스의 종류도 정의할 수 있을 것이다.

     

    [ServiceContract]

    Interface IDog

    {

       [OperationContract]

       Void Fetch();

     

       [OperationContract]

       Void Bark();

     

       [OperationContract]

       Long GetVetClinicNumber();

     

       [OperationContract]

       Void Vaccinate();

    }

     

    Class PoodleService : IDog

    { … }

     

    Class GermanShepherdService : IDog

    { … }

     

    하지만 IDog 서비스 계약의 구성은 요소화가 잘 되었다고 보기 어렵다. Fetch()와 Bark() 같은 경우는 논리적으로 관련이 있지만 GetVetClinicNumber()와 Vaccinate()는 논리성이 조금 떨어진다. Fetch()와 Bark()는 개가 가지고 있는 특성의 한 요소지만 GetVetClinicNumber()와 Vaccinate()는 다른 동물들도 가지고 있는 요소이기 때문이다.

     

    [ServiceContract]

    Interface IPet

    {

       [OperationContract]

       Logn GetVetClinicNumber();

     

       [OperationContract]

       Void Vaccinate();

    }

     

    [ServiceContract]

    Interface IDog

    {

       [OperationContract]

       Void Fetch();

     

       [OperationContract]

       Void Bark();

    }

     

    더 나은 요소화적인 서비스를 위해 IPet 인터페이스를 생성해서 GetVetClinicNumber() 와 vaccinate() 동작을 분리 시켰다. 이렇게 강아지과의 동물을 구별해 놓으면 서비스 계약의 재사용성이 가능하기 때문이다.

     

    이러한 유형에서 각각의 독립된 계약으로 정의하지 않고 계약들의 상속으로 서비스를 요소화 할 수 있다.

     

    팩토링

    서비스 계약은 하나의 동작을 갖는 것이 가능하지만 이것은 피해야 할 것이다. 서비스 계약은 어떤 개체의 특징 중 하나인데 만약 한 가지 동작으로 표현 가능하다면 그 특징은 꽤 단조로운 편이라고 할 수 있다. 이 한 동작에 대해 다음을 생각해 보자. 너무 많은 파라미터를 사용하고 있지는 않은지? 너무 조잡하여 여러 개의 동작으로 나누는 것이 좋지 않은지? 기존에 존재하는 다른 서비스 계약에 포함시켜야 하지 않은지?

     

    동작들을 요소화한 후에 각각의 동작들이 너무 세분화 되어 있지는 않은지를 살펴봐야 한다. 만약 12개 이상의 동작을 가지고 있다면 서비스 계약의 상속이나 서비스 계약의 분리로 요소화할 수 있는 방법을 정확하게 찾아 적용해야 할 것이다. 또한 코딩 표준을 정해 경우에 상관없이 넘지 말아야 할 상한선을 정하는 것이 좋다.

    (최적 멤버 수는 3~5개, 서비스 계약 안의 동작들은 6~9개의 동작이 적당)

     

    추가사항: 계약 쿼리


    저작자표시
    Posted by glycerine
    ,

    티스토리툴바