[.NET Framework]검색결과, 37건
가장 심플한 형태의 ASP.NET MVC 를 만들어 보자
모든 개발 공부는 가장 기본적인 구조에서 부터 출발하여 기술확장, 응용력확장을 해 나가는 것이 원칙이다.
처음부터 복잡한 형태를 이해하려고 하면 진입이 어려워서 쉽게 흥미를 잃어버리기 마련이다.
따라서 ASP.NET MVC 기반의 Hello World 샘플을 제작해 보도록 한다
1. ASP.NET MVC 프로젝트 생성
Visual Studio 2008 에서 새프로젝트를 만든다
아래그림과 같이 ASP.NET MVC2 Web Application 템플릿을 선택하고 프로젝트와 솔루션 이름은
HelloWorld 로 한다
확인을 클릭하면 아래 그림과 같이 유닛테스트 프로젝트 생성 여부를 묻는데,
우리는 간단한 데모를 빨리 만들어 볼 목적이므로 생성하지 않도록 한다
이렇게 프로젝트를 생성하면 VS는 자동으로 응용프로그램을 코드와 파일들을 마련해 주는데
이 자체가 하나의 ASP.NET MVC 프로그램이 된다
바로 F5를 눌러 실행시켜 보도록 하자
그러면 아래 그림과 같이 적당히 이쁜 웹 페이지를 브라우저에서 확인할 수 있다
간단한 멤버십 기능과 Home, About 링크가 제공된다
이 차제만으로도 훌륭한 샘플 데모이지만 처음 보기에는 조금 복잡해 보일 수도 있다
우리는 자체적으로 Hello World 만 출력해 볼 목적이므로 관련 파일들을 정리하도록 한다
2. 프로젝트 자동 생성 파일 정리하기
처음 생성된 프로젝트 구조를 보면 아래 왼쪽 그림과 같이 꽤 많은 파일들이 포함되어 있다
이를 오른쪽 그림과 같이 설정파일과 폴더구조만 남겨두고 모든 파일을 삭제하자
 |
=> |  |
이렇게 파일들을 제거하고 다시 실행을 해 보면 아래와 같은 오류를 보게 될 것이다
뷰와 컨트롤러를 모두 삭제했으니 페이지를 찾을 수 없다는 오류가 난 것이다
3. 뷰와 컨트롤러 생성하기
이제 Hello World 를 화면에 출력하기 위해 뷰와 컨트롤러를 생성해 보도록 하자
ASP.NET MVC 환경에서는 모든 요청의 출발은 컨트롤러(Controller)이다
컨트롤러가 요청에 대한 적절한 처리를 수행한 뒤 특정 뷰를 선택해 랜더링 되도록 한다
따라서 먼저 컨트롤러를 생성해 보도록 하자
솔루션탐색기에 Contollers 폴더에서 추가 -> Controller 해서
다음과 같이 HomeController 를 생성한다
그러면, Controller 클래스로 부터 상속받은 HomeColtroller 클래스와 Index 라는
액션메서드가 자동 생성된다. 코드를 아래와 같이 조금 수정하도록 하자
public class HomeController : Controller
{
public ActionResult Index()
{
ViewData["param"] = "HelloWorld";
return View();
}
}
ViewData 는 컨트롤러에서 뷰로 데이터를 전달하기 위한 키/값 구조로 이루어진
Dictory 형태의 자료형이며 여기에 "Hello World" 라는 문자열을 전달하기로 한다
그리고 메서드의 반환 값으로 ActionResult 인데 Index 액션 메서드가 특정 뷰를 페이지를
랜더링 하도록 하는 것이다. 여기서는 return View()로 뷰이름을 생략하였는데 기본값으로
메서드 이름인 Index 뷰(Index.aspx)를 선택하게 되는 것이다
다음으로 Index 메서드 아무 위치에서 마우스 우클릭해서 Add View 를 선택한다
이는 HomeController 의 Index 액션메서드의 뷰를 생성하는 것이다
뷰 이름은 Index로 하고 Add를 클릭하면,
프로젝트의 Views 폴더에 Home 폴더아래 Index.aspx가 생성된다
Index.aspx 의 <body> 안에 다음의 태그를 추가하자
컨트롤러에서 전달한 데이터를 뿌려주는 것이다
<body>
<div>
<%=ViewData["param"] %>
</div>
</body>
이제 다 됐다. F5 키로 프로젝트를 실행 해 보자.
아래 그림과 같이 Hello World 가 출력되는 것을 확인할 수 있다
사실 이렇게 간단한 출력을 위해서는 굳이 View 페이지나 ViewData 자료전달이
불필요 할 수 있지만, 테스트를 위해 갖추어 봤다
* URL 라우팅 잠시 살펴보기
매우 간단한 Hello World 를 다 만들어 봤다
그런데 프로젝트를 실행해서 요청 URL을 확인해 보면 다음과 같다
http://localhost:11102/
솔루션 탐색기의 Index.aspx 파일은 /Views/Index.aspx 에 있는데 말이다
게다가 정직한(?) 형태로 다음과 같이 웹 리소스 경로 그대로를 요청하면 404 Not Found 오류가 난다
http://localhost:11102/Views/Index.aspx
이유인 즉,
ASP.NET MVC는 URL 라우팅 엔진을 포함하고 있는데 이 라우팅 엔진에 의해
URL 이 해석되고 요청에 대한 컨트롤러와 액션 메서드를 선택하여 호출하게 된다
그리고 이 액션메서드에서 뷰를 선택하도록 되어 있기 때문에 URL 구조가 이전과는
다른 형태가 되는 것이다
URL 라우팅이 URL을 어떻게 해석하고 어떤 컨트롤러에게 보내야 할지 결정하게 되는
규칙을 마련해야 하는데 이 규칙은 Global.asax 파일에 다음과 같이 정의되어 있다
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 = UrlParameter.Optional } // Parameter defaults
);
}
URL 규칙은 controller/action/id 형태로 이우러지며
기본값으로는 controller = "Home" , action = "Index" 로 정의되어 있다
즉 앞서 요청과 같이 (http://localhost:11102/) 컨트롤러와 액션메서드 없이 호출하게 되면
자동으로 Home 컨트롤러, Index 액션메서드가 선택되어 실행되는 것이다
따라서 위 규칙에 맞는 다음과 같은 요청은 모두 같은 것이 된다
- http://localhost:11102/ : 컨트롤러, 액션메서드 지정 없음. 기본 값 사용
- http://localhost:11102/Home : 컨트롤러 지정, 액션메서드는 기본 값 사용
- http://localhost:11102/Home/Index : 컨트롤러, 액션메더스 모두 명시함
'.NET Framework' 카테고리의 다른 글
| ASP.NET MVC, 폼 데이타 전송하기 (0) | 2010.08.06 |
|---|---|
| ASP.NET MVC 에서 요청 매개변수 넘기기 (0) | 2010.08.05 |
| 벌써 ASP.NET MVC 3 ? (0) | 2010.08.03 |
| ASP.NET MVC가 모바일 웹에 적합한 이유 몇가지 (0) | 2010.07.23 |
| ASP.NET MVC 구성도 (0) | 2010.07.23 |
현재 프로젝트에 적용하려고 하는 기술이 ASP.MVC 버전 2 이다
그런데 ASP.NET MVC 버전 3 (Preview1) 가 출시되었다
정말 빠른 속도다
2가 나온지 얼마 됐다고 3까지... 그리고 새로운 개념이 많이 추가된 것 같다
1,2,3 에 이은 업그레이드가 이전 버전을 완전히 업어 치운것은 아니지만,
간혹 속도를 따라가기가 버겁기도 하다
http://weblogs.asp.net/scottgu/archive/2010/07/27/introducing-asp-net-mvc-3-preview-1.aspx
'.NET Framework' 카테고리의 다른 글
| ASP.NET MVC 에서 요청 매개변수 넘기기 (0) | 2010.08.05 |
|---|---|
| ASP.NET MVC, Hello World (1) | 2010.08.04 |
| ASP.NET MVC가 모바일 웹에 적합한 이유 몇가지 (0) | 2010.07.23 |
| ASP.NET MVC 구성도 (0) | 2010.07.23 |
| ASP.NET MVC 프레임워크 (0) | 2010.07.05 |
표했었다. 그리고 실제로 몇 가지 테스트를 해 보았다
: ASP.NET 웹폼 페이지가 자동 생성하는 HTML 코드 보기
이 테스트의 결과는 우려에 비해서는 대략 괜찮음(?) 이었다
몇 가지를 포기하거나 사소한 것을 무시한다면, 웹폼 모델이 웹 표준에 크게 저해되지는 않겠다 싶었다
그러나 여전히 맘 속에 남아 있는 것은 그 몇가지 이다. 마치 어거지로 끼워 맞춘다는 느낌이랄까?
ASP.NET MVC 가 웹폼에 비해 모바일.. 그리고 표준 웹에 더 적합하다는 몇 가지 이유가 있다
1) 뷰스테이트(ViewState)가 없다
뷰스테이느는 히든 값으로 서버에 전송되어 웹에서 상태유지가 가능하도록 지원되는 기술 요소이다
다만 뷰스테이트는 매번 요청 시 마다 송/수신 되므로 대역폭의 낭비가 발생한다
모바일은 대역폭에 굉장히 민감한 환경이다.
전통적인 윈도우 개발 방식의 상태유지를 포기하고 대역폭을 아끼는 쪽에 한표 던진다
ASP.NET MVC 에서도 모델 바인딩 기법을 이용하면 상태는 일부 유지되기에 더 효과적이다
2) 서버컨트롤 배제
웹폼 모델은 정말 윈도우 개발방식과 많이 닮아 있다. 설계철학 자체가 그러했으니까 당연하다
웹폼의 그 수많은 서버컨트롤. 사실 매우 유용한 컨트롤들이다. 다만 기존 환경에서는.
서버컨트롤은 자동으로 HTML 코드로 대체되고 이 코드는 표준을 준수한다고 장담할 수 없다
또한 서버컨트롤에 자동으로 부여된 ID 값은 혼란스러우며 이는 곧 자바스크립트나 CSS의 연동에
일부 제약이 있다는 것을 의미한다
ASP.NET MVC 에서는 서버컨트롤을 사용하지 않는 것이 일반적이다
물론 ASP.MET MVC 차원에서 뭔가를 획기적으로 지원해 주는 것은 아니다.
서버컨트롤을 사용하지 않을 뿐이다.
서버컨트롤을 사용하지 않게 됨으로써 자동으로 생성되는 HTML로 인한 여러 상황을 염두하지 않아도
되며 ASP.NET 의 영역과 별도로 분리하여 잘설계되고 표준적인 마크업을 사용하는 편에 한표 던진다
3) JQuery 와의 연계성
ASP.NET MVC 와 JQuery는 사실 별개의 기술이지만,
ASP.NET MVC 에서는 MVC 프로젝트 템플릿의 일부로 JQuery 라이브러리를 포함시켰다
이는 ASP.NET MVC가 JQuery 와의 연계에 노력을 했다는 증거이며 표준 자바스크립트 라이브러리의
필수성을 볼 때 바람직한 모습이다.
4) 기타 부가 요소
표준 웹, 모바일 환경과 직접적인 연관은 없지만 ASP.NET MVC 만의 매력적인 장점이 있다
- 관계 분리를 통한 좋은 유지보수성
MVC 철학 자체가 묻어 있는 장점이다. 관계 분리는 각 업무 분야의 커플링을 해소해 다른 요소에
저해받지 않고 개발, 유지보수, 확장을 가능토록 해 준다
- 관계 분리로 인한 좋은 (자동) 단위 테스트 환경
관계분리는 자동화된 테스트 시나리오, 단위 요소 테스트에 매우 적합한 모델이다
- URL 라우팅 시스템
ASP.NET MVC 에서는 URL 라우팅 개념을 도입하여 깔끔한 URL 을 만들 수 있다
이는 현재 모바일 트랜드와 정확히 일치하는 철학이며 상당히 직관적인 URL의 효과가 있다
또한 이것은 REST 의 개념과 잘 들어 맞는다
- 그리고 경험. 시도.
ASP.NET MVC는 닷넷 3.5 이상에서 펼칠 수 있는 기술이다.
그만큼 최신 기술이며 MS의 전폭적인 지원이 있다. 그리고 웹폼보다는 진보된 시도라 할 수 있다
(다 알겠지만 웹폼과 MVC의 등급은 없다. 즉 어떤게 훨씬 더 좋다라는 것이 없다는 것이다.
다만 환경에 맞는 선택만 있을 뿐이다)
새로운 기술 시도, 산업 트랜드 지향 등의 경험. 시도적 측면이 좋다
'.NET Framework' 카테고리의 다른 글
| ASP.NET MVC, Hello World (1) | 2010.08.04 |
|---|---|
| 벌써 ASP.NET MVC 3 ? (0) | 2010.08.03 |
| ASP.NET MVC 구성도 (0) | 2010.07.23 |
| ASP.NET MVC 프레임워크 (0) | 2010.07.05 |
| ASP.NET 웹폼 결과페이지 검증해 보기 (0) | 2010.07.05 |
Routing System
ASP.NET MVC 프레임워크에서는 요청 URL 에 대한 라우팅 엔진을 포함하고 있다
사실 URL 라우팅은 MVC 설계 원칙과는 별개의 주제라 할 수 있다
그러나 ASP.NET MVC 프레임워크는 현재 유명하고 유용한 웹 개발 기술을 많이 채용하고 있다
URL 라우팅 역시 그러한 일환 중 하나라고 보면 되겠다
보통 웹 요청 URL은 말그대로 웹 서버의 자원를 직접 가르키도록 되어있다
예를 들면 http://mydomainxxx.com/home/default.html 형태의 URL이며
실제 웹 서버에 있는 home 폴더의 default.html 파일을 가르키는 것이다
그러나 라우팅 엔진을 이용하면 웹 서비의 물리적인 디렉터리,파일 구조와 직접 매칭되지 않아도 된다
더불어 웹 페이지에 전달되는 파라메타 정보 역시 기존의 default.html?name1=value1&name2=value2
형태처럼 지저분(?)하지 않게 되었다.
ASP.NET MVC에서 라우팅 룰(규칙)은 Global.asax 파일에 정의되어 있다
다음에 자세히 알아 보자
Controller
어찌보면 MVC 프레임워크의 중심 역할이 아닌가 한다
모든 요청은 컨트롤러(Controller)에게 전달되고 이 컨트롤러에 의해 적절한 모델과 뷰가 선택되는 것이다. 즉 모델과 뷰의 중간에서 요청을 중계, 처리하는 역할을 한다
ASP.NET MVC의 컨트롤러 클래스는 System.Web.Mvc.Controller 에서 상속받도록 한다
역시 다음에 자세히 알아 본다
Action Method
Controller 클래스에 정의된 메서드이다
컨트롤러에서 실제 요청을 처리하게 되는 메서드라 보면 된다
특정 요청은 라우팅 룰에 의해 특정 컨트롤러의 특정 메서드로 전달된다
이를 액션메서드라고 하며 이 메서드에서 요청 처리 및 뷰 선택, 데이타 전달을 수행한다
View
사용자에게 보여지는 영역이다
즉 최종 HTML 로 랜더링 되는 페이지로써 웹 브라우저에 표시되는 영역이다
HTML과 CSS, JavaScript 와 같은 클라이언트 웹 기술이 적용되는 페이지이며
<%= %> 형태의 인라인코드로 서버측의 내용을 출력하게 된다
Model
모델을 정의하는 영역이다
모든 웹 응용프로그램은 특정 데이터를 다룬다
회원가입 시 회원데이터, 게시판의 게시물 데이터, 쇼핑몰의 상품데이터 등의 데이터들이
모델영역에 정의하게 되며 이 데이터는 컨트롤러에 의해 뷰로 전달되게 된다
ViewData
컨트롤러의 액션메서드에서 특정 뷰를 랜더할 때 전달할 데이터를 저장하는 공간이다
키/값 형태의 복수값을 저장할 수 있는 Dictory 구조로 이루어져 있다
간혹 강력한 형식의 뷰를 생성할 필요도 있는데,
이는 데이터를 정의하는 모델과 명시적으로 연결시키는 구조로 생성된다
이렇게 생성된 뷰에서는 모델의 결과데이터를 Model 이라는 키워드로 직접 액세스 할 수 있게 된다
'.NET Framework' 카테고리의 다른 글
| 벌써 ASP.NET MVC 3 ? (0) | 2010.08.03 |
|---|---|
| ASP.NET MVC가 모바일 웹에 적합한 이유 몇가지 (0) | 2010.07.23 |
| ASP.NET MVC 프레임워크 (0) | 2010.07.05 |
| ASP.NET 웹폼 결과페이지 검증해 보기 (0) | 2010.07.05 |
| ASP.NET 웹폼 페이지가 자동 생성하는 HTML 코드 보기 (0) | 2010.07.05 |
HTML5 기반 웹 사이트 개발 시 서버측 기술을 고민하다 ASP.NET MVC 패턴을 떠올리게 되었다
http://mobilepp.tistory.com/3
기존 ASP.NET 의 웹폼(Web Form) 모델의 표준 HTML 코드 생성에 의문이 생기기 시작하면서...
서버컨트롤 없는 ASP.NET 페이지, 즉 이전 ASP와 유사하게 요청에 대한 처리만 서버페이지에서
담당하고 프리젠테이션 부분은 <% ... %> 블럭 내 처리를 해 보는 것을 생각해 보았다
그러던 중, 서버컨트롤 및 뷰스테이트 등에 의존하지 않은 모델인 MVC를 떠올리게 되고
ASP.NET MVC 프레임워크로 자연스레 눈이 가게 되었다
물론 MVC 패턴과 서버컨트롤의 사용 유/무와는 무관하다
MVC 패턴 자체가 닷넷의 기술도 아니고 MS에서 만든 패턴도 아니다
이는 모델과 뷰, 그리고 이를 중재하는 컨트롤러의 명확한 구분으로 각 부문간 커플링을 제거하고 효율적이고 유지/보수성이 좋은 개발환경을 위한 패턴이다
MS에서 만든 ASP.NET MVC 프레임워크는 MVC 패턴 구현을 위한 도구적 지원에 가까우며
그 가운데 서버컨트롤의 사용이 배제되는 것이다
어찌되었던 기존 ASP.NET 으로 표준 웹 사이트를 개발하고 싶은 나의 요구사항은
서버컨트롤의 사용을 배제하고 싶은 쪽으로 기울어졌고 여기에 더불어 효과적인 웹 개발 패턴이 어울어지며 이를 도구차원에서 지원해 주는 ASP.NET MVC 프레임워크의 선택으로 가닥이 잡히고 있는 것이다
ASP.NET MVC 프레임워크를 인터넷에서 잠시 훓어 보니, 생각했던것보다 매력적임을 느끼고 있다
재미있는 기술은 나의 인생을 바쁘게 만들지만 흥미롭게도 만든다
'.NET Framework' 카테고리의 다른 글
| 벌써 ASP.NET MVC 3 ? (0) | 2010.08.03 |
|---|---|
| ASP.NET MVC가 모바일 웹에 적합한 이유 몇가지 (0) | 2010.07.23 |
| ASP.NET MVC 구성도 (0) | 2010.07.23 |
| ASP.NET 웹폼 결과페이지 검증해 보기 (0) | 2010.07.05 |
| ASP.NET 웹폼 페이지가 자동 생성하는 HTML 코드 보기 (0) | 2010.07.05 |
앞서 테스트를 통해 ASP.NET 서버컨트롤, 이벤트, 바인딩 등으로 자동 생성되는 HTML 태그가 표준 웹구현상 그리 큰 문제가 되지 않겠다는 1차 결론을 내렸다
관련 글: http://mobilepp.tistory.com/entry/ASPNET-페이지가-자동-생성하는-HTML-코드-보기
그렇다면 ASP.NET 결과페이지가 HTML5 문서로써 적합한가를 검증해 보도록 하자
http://html5.validator.nu 라는 사이트는 HTML5 문서를 검증해 주는 서비스를 제공한다
웹 페이지 URL 이나 소스 업로드 혹은 직접 코딩 등을 통해 HTML5 문서 검증을 수행해 준다
앞서 테스트에서 사용된(GirdView 바인딩 예제)의 결과 HTML 을 검증해 보았다
(아래 HTML 코드가 검증 대상 코드이다)
|
버턴이 클릭되었습니다 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" <html xmlns="http://www.w3.org/1999/xhtml"> </title></head> <div> <input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWAwKb0uO9CgLs0bLrBgKM54rGBgPmVLMaYbGQ70XAJcWmf4x4h8E+" /> |
일단 검증전에, 눈에 딱 거슬리는 몇 가지.. 있긴 하다
HTML5의 공식 도뮤먼트타입인 <!DOCTYPE html> 에 위배되는 모습이다. 일단 검증을 돌려보자
아래 그림은 결과화면의 일부를 캡쳐 받은 것이다
역시 HTML5 처음에 DockType이 제일 처음 위치해야 한다는 내용과 틀린 DockType이라는 에러가 보고된다. 그리고 이로 인해 head 와 title 등과 같은 정상 태그들도 그 위치가 애매하다고 한다
그렇다면 문서의 상단에 DockType 부분을 수정하고 다시 검증해 보자
|
<!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml"> |
예상했던대로 이전에 많던 오류보고가 대부분 사라졌다
다만 GirdView 가 변환된 table 태그에 cellspacing, rules, border 속성들이 obsolete,
즉 구식속성이라 보고된다. 보고서에서는 이 속성들 대신에 CSS를 사용하라고 권장(?)도 해 준다
HTML5가 하위호환성을 가지고 있기 때문에 이와같은 표현(display)과 관련된 속성 오류는
동작에는 직접적인 연관이 없겠지만 CSS 연동 및 스크립트 연동에는 제약이 예상된다
아래 글은 아는 후배의 블로그에서 공감가는 부분을 발췌한 것이다
* 제약이 많은 HTML 기반의 컨트롤
서버 컨트롤은 자신을 HTML로 렌더링 하기는 하지만 대체로 웹 표준을 만족 하지 못하거나 CSS를 적용 하기 어려운 구조이다. 또한 서버 컨트롤이 생성한 클라이언트 ID 값은 예측 하기 어렵고 복잡하여 JavaScript로 접근 하기 매우 어렵다
[출처] ASP.NET MVC 도입 해야 할까?|작성자 쭌스
다만 아직 결론을 내리기는 힘들고, ASP.NET 의 MVC 패턴 프레임워크를 추가로 살펴보기로 하자
'.NET Framework' 카테고리의 다른 글
| 벌써 ASP.NET MVC 3 ? (0) | 2010.08.03 |
|---|---|
| ASP.NET MVC가 모바일 웹에 적합한 이유 몇가지 (0) | 2010.07.23 |
| ASP.NET MVC 구성도 (0) | 2010.07.23 |
| ASP.NET MVC 프레임워크 (0) | 2010.07.05 |
| ASP.NET 웹폼 페이지가 자동 생성하는 HTML 코드 보기 (0) | 2010.07.05 |
관련 글: http://mobilepp.tistory.com/entry/HTML5-서버측-기술은
그렇다면 ASP.NET 이 자동생성하는 각종 HTML 태그가 어떤 것인지, 그리고 이러한 코드가 HTML5 와 연동시 어떤 해악(?)을 끼치는지 알기 위해 우선 ASP.NET 페이지가 자동생성하는 HTML 코드들을 살펴 보기로 했다
1. 우선 Visual Studio 에서 ASP.NET 웹 사이트 하나 생성하고 아무런 추가 없이 랜더링 해 봤다
- VS에서 자동 생성한 ASP.NET 페이지의 HTML 코드
|
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> <!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"> |
- 브라우저에서 랜더링된 HTML 코드
| <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head><title> </title></head> <body> <form name="form1" method="post" action="Default.aspx" id="form1"> <div> <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwULLTE2MTY2ODcyMjlkZBzInEDcqzrCotILM3qJEQA/uDC7" /> </div> <div> Hello, World! </div> </form> </body> </html> |
ASP.NET 서버컨트롤이나 서버이벤트, 자동 바인딩 등 .NET 의 고유기술을 사용하지 않은 결과 HTML은 일반적인 태그들 밖에 없어 일단 안심이다.
ASP.NET 의 웹 폼 상태관리를 위한 뷰스테이트(VIEWSTATE)가 보이기는 하지만 어차피 HTML의 숨겨진(hidden) 입력 필드(input)로 처리되기 때문에 웹 표준을 저해한다고 할 수 없을 것 같다
2. 이제 ASP.NET 서버컨트롤을 올려보고 이벤트를 등록할 경우, HTML 은 어떻게 될지 살펴 보자
- VS에서 서버컨트롤(버턴) 올리고 텍스트박스 올리고 버턴 이벤트 처리를 하였다
|
<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> <!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"> |
- 브라우저에서 랜더링된 HTML 코드
|
버턴이 클릭되었습니다 <!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"> </title></head> <div> <input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWAwLc0ImlCgLs0bLrBgKM54rGBh+lsCmZJPKGcsDW8qAdtWslAPVy" /> |
서버컨트롤의 이벤트를 등록하니 __EVENTVALIDATION 이라는 히든요소가 추가되었다
그러나 이 역시 기본 웹 폼 요소이기에 상관없을 듯 하다
참고로 웹 폼 상태유지도 무난히 통과~
3. 이제 GridView 컨트롤에 데이타소스를 바인딩 시켜보자
- VS에서 GridView 추가하고 코드비하인트에서 데이타소스를 바인딩 시켰다
|
- 나머지 다 동일. 페이지에 GridView 컨트롤 추가 DataTable dt = new DataTable("MyData"); dt.Rows.Add("mkex", "박종명"); this.GridView1.DataSource = dt; this.GridView1.DataBind(); |
- 브라우저에서 랜더링된 HTML 코드
|
버턴이 클릭되었습니다 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" <html xmlns="http://www.w3.org/1999/xhtml"> </title></head> <div> <input type="hidden" name="__EVENTVALIDATION" id="__EVENTVALIDATION" value="/wEWAwKb0uO9CgLs0bLrBgKM54rGBgPmVLMaYbGQ70XAJcWmf4x4h8E+" /> |
뷰스테이트 양이 꽤 늘어난 것과 GridView 컨트롤이 자동으로 table 태그로 변환된 것을 알 수 있다
역시 표준 HTML 코드에는 상관이 없을 듯 하다
음.. 그렇다면 ASP.NET 이 자동생성하는 코드는...
상태유지를 위한 뷰스테이스는 히든필드로 생성되고
이벤트처리를 위해 EVENTVAL.. 역시 히든필드가 생성되고
목록컨틀롤인 GridView 에 바인딩한 것은 table 태그로 변환되는 것을 알 수 있었다
나의 생각이 기우였던가??? 무지였던가 ㅎㅎ;
일단 이 테스트로는 ASP.NET 과 HTML5 연동에는 무리가 없어 보인다
'.NET Framework' 카테고리의 다른 글
| 벌써 ASP.NET MVC 3 ? (0) | 2010.08.03 |
|---|---|
| ASP.NET MVC가 모바일 웹에 적합한 이유 몇가지 (0) | 2010.07.23 |
| ASP.NET MVC 구성도 (0) | 2010.07.23 |
| ASP.NET MVC 프레임워크 (0) | 2010.07.05 |
| ASP.NET 웹폼 결과페이지 검증해 보기 (0) | 2010.07.05 |
