ASP.NET 웹 폼

Web Development

by thankee 2007. 12. 29. 06:36

1. ASP.NET의 페이지 구조

* 기본적으로 ASP.NET의 페이지구조는 A라는 웹페이지를 생성하면, A.aspx라는 페이지 파일과, 그 이벤트를 처리할 A.aspx.cs파일(C#문법의 경우)이 한 쌍으로 생성됩니다.
(Visual Basic.NET문법은 A.aspx.vb, J#(Java)문법의 경우 aspx파일에 포함)

* 디자인페이지와 그것을 처리할 코드페이지를 분리함으로서 웹디자이너와 웹프로그래머가 보다 더 효율적으로 작업할 수 있게 됩니다. 웹디자이너는 디자인페이지만, 웹프로그래머는 코드페이지에 작업을 전념하면 되기 때문입니다. 따라서 ASP.NET를 작업할 때 명심해야하는 부분은 aspx 파일에는 컨트롤 배치 이외에 웹프로그래머가 직접 코드를 작성하는 경우를 최소화해야한다는 것입니다. 물론 프로그래머가 ASP스타일처럼 aspx파일 하나에 코드와 디자인 코드를 모두 기술할 수 있습니다. 하지만 그렇게 할 경우 ASP.NET의 장점을 무시하고 ASP방식을 따르는 것이므로 어떻게보면 ASP로 작성하는 것보다 못한 페이지가 될 수 있겠죠. 또한 이렇게 분리하여 작성함으로서 유지보수시나 가독성 향상에도 엄청난 도움이 됩니다.

* aspx파일을 웹 폼이라고 합니다. 일반 HTML작성 시 기본적으로 입력해야 하는 부분이 <body>태그까지라고 한다면, ASP.NET은 <body>태그 안의 <form>태그까지라고 보시면 됩니다. 즉 모든 출력에 관한 코드는 <form></form>태그 안에 기술 됩니다.

* ASP.NET은 XHTML1.0을 기반으로 페이지가 작성됩니다. 간단히 XHTML에 대해 설명한다면, HTML의 태그를 xml로 정의하여 사용하는 것이라고 할 수 있습니다.

2. 서버 컨트롤

* HTML에서 데이터를 전송하기 위해 사용하던 기본적인 컨트롤들은(<input>, <select>등) ASP.NET에서 서버 컨트롤로서 제공되고 있습니다. 예를 들면 <input type=text>, <input type=password>, <textarea>태그들은 <ASP : TextBox>라는 서버컨트롤로서 통합되어 제공되고 있습니다. HTML에서 사용하였던 각 컨트롤을 서버컨트롤로 제공하는 것은 물론이고, 추가적으로 다양한 사용자 편의를 위한 컨트롤을 제공합니다.

3. 이벤트 처리기(Event Handler)

* 이벤트가 발생할 경우 그 이벤트를 처리하는 메서드들을 보통 이벤트 처리기라고 합니다. ASP.NET에서 제공하는 서버컨트롤들은 대부분 고유한 이벤트를 발생시키며, 이벤트 처리기로 처리될 수 있습니다. 물론 이벤트가 존재하지 않는 서버컨트롤도 존재합니다. 만약 여러 이벤트가 동시에 발생할 경우 이벤트의 우선순위가 존재하여, 순차적으로 처리됩니다. 만약 이벤트 처리도 중 Response.Redirect()나 Response.End()구문을 만나면 아직 처리되지 않은 이벤트가 있더라도 무시하고 페이지 전환 또는 실행 중지됩니다.

* 가장 빈번히 사용되는 TextBox 서버컨트롤과 Button 서버컨트롤의 이벤트가 동시에 발생할 경우(텍스트 변경이벤트와 버튼 클릭이벤트가 된다) TextBox이벤트가 우선하며, Button이벤트는 TextBox이벤트 후에 실행됩니다. 마찬가지로 모든 aspx페이지는 로드될 때 page_load이벤트가 발생하는데, 모든 이벤트보다 우선순위가 높은 것이 page_load이벤트입니다.

4. ASP.NET의 내장 객체(Built-in Object)

* ASP.NET에서는 다양한 내장 객체를 제공합니다. Response, Request, Server, Application, Session이 모두 내장 객체로 제공됩니다.

(1) Response 객체 : 클라이언트 측으로 응답을 위한 용도로 사용되는 객체입니다. 이 객체의 메서드 또는 필드는 다음과 같습니다.

- Write() : 해당위치에 내용을 출력

- Redirect() : 다른 페이지로 이동

- WriteFile() : 해당위치에 파일의 내용을 그대로 출력합니다. 파일의 크기가 큰 경우 예외가 발생할 수 있습니다.(파일 크기에 대한 제한은 Platform마다 다릅니다.) <#include file>과 차이점은 해당위치에 출력된 파일 내용을 해석하지 않고 그대로 클라이언트로 전송한다는 점입니다. 예로 A.aspx페이지에서 Response.WriteFile("B.aspx");라고 할 경우, A.aspx에 B.aspx의 파일 내용이 출력되며, 출력된 코드는 해석되지 않고 그대로 클라이언트에 전송됩니다.(즉 B.aspx의 소스코드가 클라이언트의 브라우저에 그대로 나타나게 됩니다.)

- Expires : 페이지 소멸시간(분)을 결정합니다. 모든 SSS(Server Side Script)페이지는 Parser(해석기)에 의해 한번 해석되면, 해석된 결과가 캐시에 저장되며, 사용자가 재차 같은 페이지를 Refresh(포스트 백)할 경우나 그 페이지로 돌아갈 경우, 페이지를 매번 해석하지 않고, 캐쉬에 있는 해석된 페이지를 사용자에게 전달합니다. 캐시에 해당 페이지가 존재하는 시간을 Expires로 조절할 수 있으며, -1의 경우 매번 Parser가 해당 페이지를 새로 해석하게 됩니다.(Expires = -1의 사용에는 신중을 기할 필요가 있습니다.)

- Buffer : 페이지를 버퍼링 할지 결정(Default값 : true)

- Flush(), Clear(), End() : Buffer속성이 true가 되어 버퍼링이 활성화 되면, Flush(), Clear(), End()메서드 사용이 가능합니다. Flush()는 해석된 내용을 클라이언트로 출력하며 버퍼링을 계속합니다. Clear()는 해석된 내용을 클라이언트로 전송하지 않고 지워버리며 버퍼링을 계속합니다. End()는 해석된 내용을 클라이언트로 출력하고 버퍼링을 중단합니다.

- Cookies[] : 클라이언트에 쿠키를 남깁니다. Cookies는 각각 HttpCookie객체로 이루어져 있으며 따라서 사용방법이 ASP와 조금 다르게 됩니다. HttpCookie객체는 키와 값으로서 데이터를 저장, 관리합니다. 키는 String과 Int형 모두 가능합니다. 각 HttpCookie객체는 Expires 속성 값을 가지는데 이 속성 값은, 클라이언트에서 해당 쿠키의 만료시간을 결정하는 것입니다. 쿠키 객체의 사용가능여부는 클라이언트의 설정에 의존합니다. 클라이언트에서 쿠키를 사용하지 않도록 설정한다면, 서버에서 쿠키를 지정해도 클라이언트에는 저장되지 않으므로 주의가 필요합니다.

방법 1(단일값 할당방법)
할당 : Response.Cookies["키“].Value = ”값“;
만료시간결정 : Response.Cookies["키”].Expires = DateTime.Now.AddDays(1);
사용 : Response.Write(Request.Cookies["키”].Value);//쿠키에 저장한 값 찾기

방법 2(위의 방식을 풀어서 보면 아래와 같습니다.)
HttpCookie hc1 = new HttpCookie(“키”);
hc1.Value = “값”;
hc1.Expires = DateTime.Now.AddDays(1);
Response.Cookies.Add(hc1);
HttpCookie hc2 = Request.Cookies["키“];//쿠키에 저장한 값 찾기
Response.Write(hc2.Value);

방법1(딕셔너리 형식(다중 키 값)으로 사용하는 방법)
Response.Cookies ["상위키"]["하위키"] = "값";
Response.Cookies["상위키"].Expires = DateTime.Now.AddDays(1);
Response.Write(Request.Cookies[”상위키“][”하위키]);//쿠키에 저장한 값 찾기

방법2(위의 방식을 풀어서 보면 다음과 같습니다.)
HttpCookie hc1 = new HttpCookie("상위키");
hc1.Values["하위키"] = "값";
hc1.Expires = DateTime.Now.AddDays(1);
Response.Cookies.Add(hc1);
HttpCookie hc2 = Request.Cookies["상위키]; //쿠키에 저장한 값 찾기
Response.Write(hc2["하위키]);

(2) Request 개체 : 클라이언트로부터 전송받은 값을 얻기 위해 사용합니다.
* 클라이언트에서 서버로 데이터를 전송하는 방식은 크게 두가지로 나뉘어집니다. 첫째는 Get방식으로 하이퍼링크를 통해서 데이터를 전송하는 것이고, 둘째는 Post방식으로 Http헤더에 데이터를 포함하여 전송하는 것입니다. 두가지 방법모두 장단점이 있으며 특징이 있기에, 상황에 따라서 선택하여 쓰시면 됩니다.

* Get방식이 일반적으로 속도가 빠르며, 하이퍼링크를 작성하는 것만으로 데이터를 전송할 수 있는 반면에, 하이퍼링크에 데이터가 노출되기 때문에 보안상의 문제가 될 수 있으며 전송될 수 있는 데이터의 양도 제한적이라는 점입니다. 아래의 방법으로 하이퍼링크에 데이터를 포함하여 전송하실 수 있습니다.
<a href="http://주소.com?키=값&키2=값2">링크문자열</a>
위와 같이 하이퍼링크를 작성하시면, 서버에서 키와 키2로 데이터를 얻을 수 있게됩니다.

* Post방식은 Http헤더에 데이터를 포함시키기 때문에 데이터가 노출되지 않을 뿐더러, Get방식 보다 데이터의 전송 양이 큰점이 장점이라고 할 수 있습니다. 반면에 Http Encoding와 Decoding에 시간이 필요하기 때문에 Get방식 보다 조금 더 느리다는 단점이 있습니다.

- QueryString[] : Get방식으로 전달된 데이터를 받기위해 사용됩니다.

- Form[] : Post방식으로 전달된 데이터를 받기위해 사용됩니다.

- Params[] : Get/Post 모든 방식으로 데이터를 전송 받으실 수 있습니다. Request["키"]와 Request.Parmas["키"]는 동일한 기능을 합니다.

- Url : 현제 페이지의 Url반환(http://localhost:2060/WebRoot/Page.aspx)

- UrlReferrer : 이전페이지의 Url반환
(이전 페이지 이름이 Previous.aspx라면, http://localhost:2060/WebRoot/Previous.aspx 반환)

- Path : 현제 페이지의 가상 경로반환(./WebRoot/Page.aspx)

- ApplicationPath : 현재 웹사이트의 루트 가상 경로를 반환.(./WebRoot)

- PhysicalApplicationPath : 현재 웹사이트의 루트 물리 경로를 반환(C:\WebRootFolder\)

- PhysicalPath : 현재 페이지의 물리경로 반환(C:\WebRootFolder\Page.aspx)

- UserAgent : 접속자의 환경 정보 제공(브라우져 명, OS명 등)

- Browser : 접속자의 브라우져 명 제공

- UserHostAddress : 접속자의 IP를 반환

- ServerVariables[] : 주요 서버 환경 변수 값을 얻기위해 사용

- Cookies[] : 클라이언트에 저장한 쿠키 값을 가져오기 위해 사용(예제는 Response객체의 Cookies예제 참조)

(3) Server 개체 : 가상경로를 물리경로로 바꾸던지, 다른페이지로 제어권을 넘기는 등의 유용한 메서드와 기타 정보를 제공합니다.

- ScriptTimeout : 하나의 ASPX페이지 처리가 지연될 경우, 최대 얼마까지 지연될 수 있는지 설정

- MachineName : 서버 컴퓨터 이름 반환

- Execute() : 이 메서드가 사용되면, 매개변수로 지정한 페이지로 제어권을 넘긴 뒤, 해당 페이지 처리가 끝나면 다시 현재 페이지로 제어권이 돌아오게 됩니다. 즉 A.aspx페이지에서 Server.Execute(B.aspx)라는 구문을 만나면, B.aspx페이지를 읽어서 그 안의 내용을 처리하고, 다시 A.aspx로 돌아가 남은 페이지 처리를 마무리하게됩니다.

- Transfer() : Execute와 비슷하다. 매개변수로 지정한 페이지로 제어권을 넘긴 뒤, 다시 제어권이 돌아오지 않고 처리가 마무리 됩니다.

- UrlEncode() : 문자열을 매개변수로 받아, URL인코딩을 실시합니다. Get방식은 URL의 끝에 데이터를 첨부하는 것인데, 이때 첨부되는 데이터가 한글이나 특수문자들일 경우 문제가 될 수 있습니다. 따라서 전송될 데이터를 UrlEncode()라는 함수로서 Url Encoding하게 됩니다. Url Encoding하면 한글이나 특수문자들은 %숫자 형태로 변경됩니다.

- UrlPathEncode() : UrlEncode()와 비슷하다. 하지만 #, ?, &, =, 공백 등 특수 문자들은 Url Eocnding되지 않습니다.

* 원본 : D:\내문서\H i?a=b&c=d
* UrlPathEncode : D:\%eb%82%b4%eb%ac%b8%ec%84%9c\H%20i?a=b&c=d
* UrlEncode : D%3a%5c%eb%82%b4%eb%ac%b8%ec%84%9c%5cH+i%3fa%3db%26c%3dd

- UrlDecode() : Url Encoding된 문자열을 매개변수로 받아, Encoding전의 데이터로 되돌립니다.

- MapPath() : 가상 경로를 매개변수로 받아, 실제 물리 경로를 반환합니다.

- HtmlEncode() : 문자열을 매개변수로 받아, HTML인코딩을 실시합니다. 예로, < 또는 > 기호는 < 또는 >로 변경됩니다.

- HtmlDecode() : Html 인코딩 된 문자열을 매개변수로 받아, HTML디코딩을 실시합니다. HtmlEncode()의 반대로 생각하시면 됩니다.

(4) Application 개체 : 해당 웹사이트 전역에서 모든 세션이 공유할 수 있는 Application Level 변수를 사용, 관리할 수 있도록 해줍니다. 또한 Application Level에 관한 기능이나 정보를 제공하는 역할도 합니다.
- Add(), Get(), Set(), GetKey() : 각각 Application Level 변수를 지정, 참조, 수정, 키의 반환등의 역할을 한다. Application Level의 데이터는 컬렉션으로 관리됩니다.

Add("키", "값");    //키와 값을 이용하여 컬렉션에 데이터 저장.
Get("키");       //키에 해당하는 데이터를 반환.
Set("키", "값"); //키에 해당하는 위치에 값을 적용.
GetKey(인덱스);    //컬렉션의 인덱스에 해당하는 키 값 반환.

- Clear(), Remove(), RemoveAll(), RemoveAt() : Clear, RemoveAll은 지정한 Application Level로 지정했던 모든 변수를 삭제합니다(모든 컬렉션 삭제). Remove("키")나 RemoveAt(인덱스)는 해당 컬렉션만 삭제합니다.
- Lock(), UnLock() : 동시에 여러 세션이 참조함으로서 발생하는 무결성 위반을 방지하기 위해 사용됩니다. 예를들어 Applicaton Level의 변수로 카운터를 관리한다고 할 때, 기존의 카운터 값은 1이였고, 동시에 두명의 방문자가 접속하여 각각 카운터에 +1을 했다고 합시다. 상식적으로는 카운터가 3이 되어야하지만 2가 되버립니다. 왜냐하면 동시에 두 세션 모두 카운터에 접근했기 때문에, 두 세션모두 기존의 카운터 값인 1에다가 +1을 하였기 때문입니다. 동시에 데이터로 접근하는 것을 막고, 순차적으로 접근도록 하는 것이 해결책이 되며 이를 위해 ASP.NET에서는 Lock()과 UnLock() 메서드를 제공하고 있습니다. Lock()메서드와 UnLock()메서드 사이의 모든 구문은 여러 세션이 동시에 참조 할 수 없고, 순차적으로 참조됩니다. 아래와 같이 사용될 수 있습니다.

Lock(); //임계영역 지정(Critical Section)
Application["Counter"] = Application["Counter"] + 1;
Response.Write("현재 방문자 수는 " + Application["Counter"] + " 입니다.");
UnLock(); //임계영역 해제

(5) Session 개체 : 해당 세션 내에서는 어디서라도 참조할 수있는 Session Level 변수를 사용, 관리할 수 있도록 해줍니다. 또한 세션에 관련된 기능이나 정보를 제공하는 역할도 합니다.
* Session Level 변수의 사용에는 신중을 기할 필요가 있습니다. 사용자가 웹사이트에 접속할 경우 접속자마다 각각 하나의 세션이 생성되게 되는데, 웹사이트에서 Session Level 변수를 하나만 사용하였다고 하더라도, 동시 접속자가 1만명이면 세션이 1만개가 생성되므로 시스템 성능은 엄청나게 떨어지게 됩니다. (사용자가 접속을 끊는다고 하더라도 세션이 바로 사라지는 것은 아니기 때문에, 실제로 유지되는 Session은 동시 접속자 수보다 항상 많다고 보시면 됩니다.) 따라서 Session Level 변수의 사용에 대해서는 신중을 기할 필요가 있습니다. 세션변수를 남용하다 보면, 동시 접속자 수가 2-3백명 정도만 되어도 서버가 다운되는 모습을 볼 수도 있습니다.
- SessionID : 세션마다 고유한 값을 반환합니다.
- Timeout : 특정 세션에서 Timeout에 지정된 시간(분)동안 요청이 없으면, 해당 세션이 종료됩니다.
- Abandon() : 세션을 강제로 종료시킵니다.
- Add(), Clear(), Remove(), RemoveAll(), RemoveAt() 등은 Application에서의 메서드와 동일하며, 그외 메서드는 제공되지 않습니다.

Session 변수나 Application변수 사용시 Application["키"] = "값";, Session["키"] = "값";으로 하시면 됩니다. Session["키"]의 경우 해당 값을 참조하는 것입니다.

(6) Global.asax : Global.asax파일을 사용하면 Application_Start(), Application_End(), Session_Start(), Session_End()의 메서드를 지정할 수 있습니다. 새 항목 추가에서 전역 응용 프로그램 클래스를 추가하시면 Global.asax파일이 생성됩니다.
- Application_Start() : 웹사이트가 개설되고 첫 방문자가 접속 할 경우 실행되는 메서드 입니다.
- Application_End() : 웹사이트가 종료되는 시점에 실행되는 메서드 입니다. 즉 모든 세션이 종료되는 순간 실행되게 됩니다.
- Session_Start() : 사용자 접속시마다 실행되는 메서드입니다.
- Session_End() : 세션종료 시에 실행되는 메서드입니다. 사용자의 마지막 요청 후 Timeout속성에서 지정한 시간동안 요청이 없으면 세션이 종료되게 되는데 그 시점에 실행됩니다.
- Application_Error : 사용자가 처리하지 않은 예외(오류)가 발생 할 경우 이 메시더그 실행됩니다.
- 그 외 ASP.NET에서는 Global.aspx에서 제어할 수 있는 보다 다양한 이벤트 함수를 제공합니다.

by thankee from tistory.com