20210407
ASP.NET 웹폼이란 무엇인가?
ASP.NET에 들어서면서 페이지 작성시 가장 먼저 개발자들이 만나게 되는 것이 바로 웹 폼(WebForm)이라는 것입니다. 웹에서 사용하는 폼이라는 의미인데, 이것은 마치 웹 페이지를 일반 어플리케이션 폼을 작성하듯이 만들 수 있게 해 주는 웹 페이지 구조를 말합니다.
여러분이 VC++ 이나 VB 등을 다루어 보았다면, 여러분이 윈도우를 꾸미기 위해서 제공되는 폼 위에다가 필요한 컨트롤들을 그냥 Drag and Drop 으로 올려다 놓으면 그것으로 폼이 후딱 만들어지던 것을 보셨을 겁니다. VB나 VC++ 에서는 간단한 구성의 폼을 하나 꾸미는 데는 10초도 걸리지 않습니다. 그렇게 쉽고 간단하지요. 그러한 기능이 이제 Visual Studio.NET을 통해서 제공이 된다는 것입니다. 물론, 직접 손으로 예전처럼(ASP 때처럼) 코딩해도 상관은 없습니다.
하지만, 그렇게 만들어지는 페이지의 HTML 소스나 소스코드를 보면 그리 쉽게 이해가 가지 않는 모습을 띄고 있지요. 이는 ASP.NET 의 웹 페이지 자체가 하나의 객체로써 구성되어지고, 상속되어진 클래스의 구성을 하고 있기에, 언어기반의 프로그래밍 경력이 없는 이들에게는 대단히 어렵고 복잡하게 받아들여질 수 있기 때문입니다. 잠시 후 이러한 예제들을 만나보게 될 것입니다.
ASP.NET 은 이벤트 중심의 프로그래밍을 지향합니다. ASP 때의 코딩방식에서 완전히 탈피한 스타일이라 이 부분은 ASP 식의 프로그래밍에 익숙하신 분들은 오히려 혼란스러울 수 있기까지 한 부분일 수 있습니다.
자바스크립트에 익숙한 사람이라면 흡사 코드가 클라이언트측에서 어떤 이벤트를 처리하는 부분처럼 느껴질 수도 있습니다. 그리고, 이 예제는 솔직히 굳이 서버에서 처리하지 않아도 되는 예제이기는 합니다. 하지만, 우리에게 중요한 것은 이 페이지의 소스가 서버에서 처리된다는 것입니다.
현재 웹개발 방식은 더이상 서버 상에서, HTML을 처리할 필요가 없습니다. 클라이언트의 성능이 좋아졌기 때문에, 서버의 역할은 많이 축소되고, 클라이언트 단에서 Javascript 또는 Typescript를 통해 데이터를 가공하기도 하고, 여러가지 비즈니스 로직을 수행합니다.
그러나 웹폼은 서버 상에서 HTML 을 가공하여, 다시 클라이언트로 보내주는 방식으로 동작합니다. 상대적으로 클라이언트의 역할은 적고, 서버의 역할은 많은 편입니다. 2008년도 이전의 개발접근 방식이라서, 현재의 개발 프레임워크와는 개발 접근 방식이 다릅니다.
그래서, 현재는 대부분이 싱글 페이지 프레임워크 형식에 컴포넌트 기반 개발 방식을 따르기 때문에 아래의 순서대로 접근하게 됩니다.
0. 프레임워크의 이상적인 전체구조 파악
- Main에서 시작해, Routor를 통해 페이지를 이동하는 방식
1. 라우터 정의
2. 각 페이지별 템플릿 / 스타일 / 로직으로 이루어진 Page Component 구현
- 상황에 따라 Popup으로 쓰일 Page Component 구현
3. 템플릿 / 스타일 / 로직으로 이루어진 Common Component 구현
- 데이터 전달 흐름
[Parent -> Child, INPUT 변수], [Child -> Parent, OUTPUT 이벤트]
4. 공용 서비스(Service) / 유틸(디렉티브, 파이프, 가드) 구현
5. DB 모델(Model)
그러나, 웹폼은 일단 페이지별로 개발을 수행합니다. ex) articleList.aspx, writeArticle.aspx 형식으로, 페이지를 구현한 후에 http request를 통해 html 페이지를 post/get하는 방식으로 동작한다고 보면 된다. 웹폼은 기존 Form처럼 만들면, HTML 형식으로 변환해주는 기술이 아닐까?
마치 vb 6.0의 Web Version이라고 할 수 있다.
<html>
<script language="vb" runat="server">
Sub Button1_Click(Source As Object, E As EventArgs)
lblResult.Text = "안녕하시렵니까? " & txtName.text & " 님"
End Sub
</script>
<body>
<form id="Form1" method="post" runat="server">
이름 :
<asp:textbox id="txtName" runat="server"></asp:textbox>
<asp:button id="Button1" onclick="Button1_Click" runat="server" text="인사" />
<p><asp:label id="lblResult" runat="server" /></p>
</form>
</body>
</html>소스에서 <asp:textbox .. /><asp:button.. /><asp:label../>등과 같은 태그가 여러분을 당황스럽게 할런지도 모르겠습니다. 이것은 웹 폼 서버 컨트롤이라 불리는 것으로 기존의 HTML 컨트롤을 대신하게 될 서버와 연동이 가능한 컨트롤들입니다. 이름에서 느껴지듯이 이들은 각각 입력을 위한 텍스트 박스, 버튼, 레이블 이지요. 각 컨트롤의 속성으로는 runat="server" 라는 것이 들어있음에 주목하세요. 이 컨트롤들은 서버에서 연동되는 컨트롤이기에 이러한 속성이 지정되어져 있습니다. 컨트롤의 이름(Label, Textbox, Button)과 속성값(ReadOnly, Enabled, TabIndex 등)이 어디서 많이 봤나 했더니, vb 6.0에서 윈폼을 만들 때 보던 값들이었다.
각각의 컨트롤은 id 속성으로 구분을 하며, 서버에서는 그 ID로 각각의 컨트롤을 제어할 수 있습니다. 소스에서는 우리가 <asp:textbox 컨트롤에 특정 값을 넣고 버튼을 누룰 경우, 그 버튼에 걸려있는 이벤트가 서버측의 함수인 "Button1_Click"을 호출하게 됩니다. 주의하세요. 이 순간 폼의 내용은 서버로 전송되어지고, 함수가 구동되는 작업은 서버에서 일어나는 것입니다. 서버에서 말입니다.
ASP.NET의 처리방식
클라이언트 브라우저로부터 페이지가 처음 요청되는 순간, IIS는 웹 페이지를 파싱하는 ASP.NET 엔진으로 일단 페이지를 읽어들입니다. 그리고, 이를 JIT(just-in-time)로 컴파일을 합니다. 그리고, 페이지의 컨트롤들을 HTML로서 생성하면서, 컴파일된 코드가 실행되고, 호출된 이벤트가 있다면 그 이벤트 코드가 실행이 되어져서, 컨트롤과 상호작용을 하고, 출력 HTML은 생성됩니다. 그리고, 이 결과 HTML 페이지는 클라이언트의 브라우저로 넘겨지는 것입니다.
브라우저 : 페이지요청 -> IIS(ASP.NET 엔진) : 페이지 파싱 - JIT 컴파일 - HTML 파일 출력 전달 -> 브라우저
JIT Compile의 3가지 동작
1. 페이지의 컨트롤들을 HTML로서 생성
2. 컴파일된 코드가 실행
3. 호출된 이벤트가 있다면 그 이벤트 코드가 실행이 되어져서, 컨트롤과 상호작용
페이지가 처음 요청되는 경우는 위와 같은 동작을 하지만, 두번 이상 호출되어지면 컴파일을 하는 작업은 사라지고, 이미 컴파일이 되어져 있던 것을 사용하게 되기에, 이후 요청시는 페이지의 수행시간이 단축되어 집니다. 이를 그림으로 표시하면 다음과 같습니다.
Visual Studio 에서 webform(.aspx)를 생성, 즉 ASP.NET 페이지를 만들게 되면 기본적으로 Code Behind 로써 페이지가 구성이 됩니다. 즉, 페이지의 컨텐츠 페이지와 실제 로직 부분이 각각의 페이지로 구성되어지고 연결되어진다는 것이지요. 사실 .aspx 는 윈폼처럼 Web 페이지를 만들려고 고안된 것이기 때문에, 좌표로 위치를 지정할 수 있는 방식(DHTML?) 또는 기본 HTML 방식으로 만들수 있다고 한다. 그러나, 기본 HTML 방식을 쓰는 것이 표준에 맞지 않을까 싶다.
Angular의 경우, 하나의 Page Component가 클라이언트 내에서 해당 페이지에 대한 요청을 처리하고 Rendering 하는데까지 모두 총괄한다. 그러나 Asp.net의 Webform Page는 클라이언트에서 처리할 부분과 서버에서 처리해주어야할 부분을 명확하게 나누어 구현한다. 이는 모던 프레임워크 내에서는 브라우저가 HTML을 모두 처리할 수 있는 성능이 되는 반면, Webform이 나오던 시기에는 성능상 ASP.NET 서버 상에서 HTML을 처리 후, 브라우저로 보내야했기 때문이다. 실제로 .aspx 파일 내부에 runat="server"라고 명시되지 않은 태그나 스크립트 등은 클라이언트 브라우저 상에서 처리하게 될 것이다.
이런 특성 때문에, 클라이언트에서 모두 데이터를 처리하고, HTML을 처리하는 경우, 한 페이지에서 새로고침이나 별도 요청 없이 여러가지 작업을 할 수 있는 반면, Webform은 하나의 작업을 처리하려면 서버를 다녀와야되기 때문에, 동일한 페이지 내부에서도 Submit이 필요한 것이다. 그리고 Submit 이후, 여러번 페이지 요청 때문에 초기화를 막고 기존 폼 상태를 유지하기 위하여 내부적으로 ViewState라는 개념을 가지고, Submit 이후에도 상태를 유지한다.
하나의 ASP.NET 페이지에는 오직 하나의 웹 폼만이 존재할 수 있다는 사실도 기억하자. 그리고, 모든 서버 컨트롤들은 반드시 웹 폼 구역안(<form runat="server"> </form>) 안에 존재해야만 한다. 그래야만 프로그래밍적으로 제어할 수 있다.
서버 컨트롤은 서버에서만 인식되는 컨트롤이다.
서버 컨트롤은 서버에서만 인식되는 컨트롤이다. 클라이언트는 서버에 그러한 컨트롤이 있는지에 대해서는 전혀 알지 못한다. 또한, 클라이언트에서는 서버측의 컨트롤에 접근할 수도 없다. 우리가 작성한 모든 코드는 서버에서 실행시에 사용되는 컨트롤들이다. 클라이언트는 단지 자신이 받아 볼 결과에만 관심이 있다. 다시 말해서, 클라이언트에게는 원래의 aspx 소스를 훔쳐볼 방법이 없다.
버튼을 클릭하는 것은 클라이언트 측의 행동이고, btnSubmit_OnClick 함수는 서버측에 있다. 클라이언트측에서 서버측의 함수를 호출할 방법은 사실상 없다. HTTP 라는 프로토콜은 연결이 유지되는 환경이 아니기 때문이다. 그럼에도, 이와 같은 방법이 가능한 것은 클라이언트가 버튼을 클릭할 경우에 무조건 폼이 서버로 서브밋되기 때문이다. 폼의 모든 데이터들이 서브밋이 되어지며, 동시에 현재 서버측의 btnSubmit_OnClick 라는 이벤트 함수를 호출하였다라는 정보도 같이 서버로 전송되어진다. 서버에서는 현재의 aspx 페이지를 다시금 생성하면서 추가적으로 btnSubmit_OnClick 라는 함수도 실행한다. 대략 이러한 식으로 페이지가 동작한다는 사실을 잠시 알아두기 바란다.
자기 자신에서 서브밋 된다는 것은 Postback이라고 지칭하며, 이는 컴파일 될 때 form action="자기자신의 url.aspx" 형식으로 변환됨으로써 구현한다.
만약 버튼이 클릭될 경우, 폼은 자기 자신 페이지로 전송이 되고, 버튼이 클릭하여 발생한 이벤트인 btnSubmit_OnClick 이라는 함수가 실행되어진다는 것은 알았는데 그런데, 만일 폼을 자기 자신 페이지가 아닌 다른 페이지로 전송한다면? 즉, 폼 태그 부분을 다음처럼 수정하여 action 을 다른 페이지로 지정한다면? 다른 페이지 내에 해당하는 클릭 콜백함수가 존재하지 않으면 문제가 발생하지 않겠는가? 그렇기 때문에, 웹 폼의 action을 개발자가 바꾸어도 ASP.NET은 그 경로를 자기자신 페이지로 강제한다.
KEY : 버튼을 클릭했을 때 일어나는 일련의 과정. POSTBACK.
포스트백!! 무척이나 앞으로 자주 만나게 될 단어이다. 굳이 번역하자면 "자기 자신으로의 전송" 이 되겠다. 너무 길다? 그렇다면 그냥 "되전송" 이란 말도 나쁘지 않아보인다
클래스의 이름은 일반적으로 aspx 페이지의 파일명을 기준으로 한다. 클래스 이름은 현재의 웹 어플리케이션 내에서 절대적으로 고유한 이름을 사용해야만 하는데, 파일명 또한 그러하기 때문에, 주로 파일명을 클래스 명으로 사용하는 것이다.
Page 태그의 Src 속성에 동일한 값을 줌으로써, 여러개의 .aspx 파일을 하나의 .cs 파일에서 처리하게 할수는 있으나, 일반적이지 않다. Inherit 속성이란 만약, .cs 파일 내에 아래와 같이 두개의 클래스를 선언 했을 경우, 선택하기 위함이지만, 일반적으로 사용되지는 않는다.
<%@ Page language="c#" Src="Start.cs" Inherits="AnotherStart"%>
// .cs 파일 내에 두개 이상의 class가 있을 경우, Inherits 속성으로 클래스명을 주어 선택할 수 있다.
// 그러나 대부분 클래스가 하나인 경우가 많다.
// .cs 파일도 여러개의 .aspx가 공유할 수 있으나, .aspx당 하나의 .cs를 만드는 것이 일반적이다.
<%@ Page language="c#" Src="Start.cs" Inherits="Start"%>
//이전 우리가 수작업을 통해서 코드 비하인드를 구성했을 경우에는 Src 라는 속성을 사용했었지만,
//.net은 Src가 표준이지만, VS.NET에서만 Codebehind 라는 속성을 사용한다.
<%@ Page language="c#" Codebehind="WebForm1.aspx.cs" AutoEventWireup="false" Inherits="TaeyoBook.WebForm1" %>
// AutoEventWireup의 경우 기본값(true)로 나두어도 상관 없지만, VS.NET은 false를 기본적으로 적용한다.
// 각각의 Event 마다 CodeBehind에 수동으로 입력해야하는 경우가 대부분이므로, false로 지정해도 상관없다.using System;
using System.Web.UI;
using System.Web.UI.WebControls;
public class Start : Page
{
protected Label lblMsg;
public void btnSubmit_OnClick(Object sender, EventArgs e)
{
lblMsg.Text = "클릭!!!";
}
}
// 새롭게 추가된 클래스.
public class AnotherStart : Page
{
protected Label lblMsg;
public void btnSubmit_OnClick(Object sender, EventArgs e)
{
lblMsg.Text = "Good Morning~~ ASP.NET!!";
}
}
VS.NET은 페이지 생성시 기본적으로 페이지 명 뒤로 cs라는 확장자를 붙인 WebForm.aspx.cs 와 같은 C# 페이지(코드 비하인드 클래스 페이지)를 생성해 주고, 연결해 준다. 이러한 코드 비하인드 페이지는 System.Web.UI.Page 라는 클래스로부터 상속 받은 하나의 C# 클래스로 구성된다. 그 클래스의 이름은 기본적으로 aspx 파일의 파일명을 사용하게 되는데, 우리의 경우 그 클래스 이름은 WebForm1이 된다.
AutoEventWireup 이라는 속성은 페이지의 이벤트가 자동으로 연결되는지 여부를 나타내는 것으로, 이벤트의 자동 연결이 설정할 것이면 true 를 그렇지 않으면 false 를 지정한다. 이 값을 지정하지 않을 경우는 자동으로 true 가 지정되는 데, 그럴 경우 페이지 내에서 발생하는 이벤트들은 모두 UI 페이지에서 OnClick=”btnSubmit_OnClick” 와 같이 이벤트 핸들러에 지정한 것만으로 처리가 이루어진다. 하지만, 코드 비하인드 페이지가 UI 페이지와 어떠한 이벤트를 주고 받을 경우(거의 모든 경우를 의미한다)에는 사실상 코드 비하인드 페이지 내에서 그 이벤트를 코드로써 등록 해 주는 추가적인 작업이 필요하다. 마치, 비하인드 페이지에서 UI 페이지의 개체를 접근하기 위해서 개체의 변수를 선언해 주었던 것처럼 말이다.
정리하자면, AutoEventWireup을 fasle 로 지정할 경우는 여러분이 코드 비하인드 페이지에 추가적인 이벤트 연결 코드를 작성해 주어야 하는 것이고, true로 지정할 경우는 어떠한 추가적인 코드도 필요하지 않음을 의미한다. 대부분 수작업으로 코드 비하인드를 구성할 경우는 일반적으로 true 인 기본값을 그대로 사용하지만(즉, 아예 이 속성을 코딩하지 않지만), VS.NET은 명시적으로 이것을 false 로 지정한 다음, 그러한 이벤트 연결 코드를 자체적으로 제공해 준다.
AutoEventWireup을 True로 주면, 페이지 내에서 발생하는 이벤트들은 모두 UI 페이지에서 OnClick=”btnSubmit_OnClick” 와 같이 이벤트 핸들러에 지정한 것만으로 처리가 이루어진다.
@Page 지시자의 AutoEventWireup 속성이 true(기본값)로 되어 있는 경우엔 닷넷 프레임 웍에서 페이지 이벤트(Page_Init, Page_Load)를 자동으로 호출 합니다.
Webform간 페이지이동 및 데이터 전달하기 3가지 방법
1. 쿼리스트링
현재웹폼
private void Button1_Click(object sender, System.EventArgs e)
{
string url;
url="anotherwebform.aspx?name=" +
TextBox1.Text + "&email=" +
TextBox2.Text;
Response.Redirect(url);
}
대상웹폼
private void Page_Load(object sender, System.EventArgs e)
{
Label1.Text=Request.QueryString["name"];
Label2.Text=Request.QueryString["email"];
}
현재웹폼에서 Response.Redirect 메소드로 대상웹폼으로 이동하게 되는데 여기서 쿼리스트링으로 넘깁니다.
ASP와 같은 방법입니다.
2. 세션
현재웹폼
private void Button1_Click(object sender, System.EventArgs e)
{
//textbox1 and textbox2 are webform
//controls
Session["name"]=TextBox1.Text;
Session["email"]=TextBox2.Text;
Server.Transfer("anotherwebform.aspx");
}
대상웹폼
private void Page_Load(object sender, System.EventArgs e)
{
Label1.Text=Session["name"].ToString();
Label2.Text=Session["email"].ToString();
Session.Remove("name");
Session.Remove("email");
}
세션을 현재웹폼에서 생성해주는데 대상웹폼으로 세션값을 전달하려면 Server.Transfer 로 대상웹폼을 끌어옵니다.
그리고 값을 유지하는것이 아니고 전달할려하기 때문에 Session.Remove 로 세션을 제거합니다.
3. 프로퍼티
현재웹폼
public string Name
{
get
{
return TextBox1.Text;
}
}
public string EMail
{
get
{
return TextBox2.Text;
}
}
private void Button1_Click(object sender, System.EventArgs e)
{
Server.Transfer("anotherwebform.aspx");
}
대상웹폼
private void Page_Load(object sender, System.EventArgs e)
{
//create instance of source web form
WebForm1 wf1;
//get reference to current handler instance
wf1=(WebForm1)Context.Handler;
Label1.Text=wf1.Name;
Label2.Text=wf1.EMail;
}
AutoPostBack 속성이란?
컨트롤의 변경 이벤트가 발생하자 마자 자동으로 서버에 submit하기 위해서는 컨트롤 AutoPostBack을 true로 설정 하면 됩니다. 서버 컨트롤 이벤트에는 OnInit, OnLoad, Onunlead, OnClick, OnPrerender, Selectindexchange, Checkchanged, Textchange등등 여러가지들이 있습니다.
CodeBehind 상에서 직접 Event 정의하기
private void InitializeComponent() {
1. 서버상에 정의된 Click 함수 매핑
this.TextBox1.TextChanged += new System.EventHandler(this.TextBox1_TextChanged);
//텍스트박스에서 값이 바뀔때의 이벤트를 델리게이트를 이용하여 정의 합니다.
this.RadioButtonList1.SelectedIndexChanged += new System.EventHandler(this.RadioButtonList1_SelectedIndexChanged);
this.Load += new System.EventHandler(this.Page_Load);
//폼로드 될때의 이벤트를 정의합니다.
// 폼이 로드 될 때 Page_Load가 실행 됩니다.
//이부분이 델리게이트를 이용
2. 클라이언트 측에 정의된 Click 함수 매핑
// 런타임에 이벤트 특성을 컨트롤에 추가하여 처리
Button1.Attributes.Add("onclick", "clientfunction();")
Button1.Attributes["onclick“] = "clientfunction();”;
}
Web Forms Page 상태관리 -> 서버 기반
1. 응용프로그램의 상태를 나타내는 HttpApplicationState에는 웹응용 프로그램에서 접근 할 수 있는 전역적인 저장의 형태이며 서버 라운드 트랩간이나 페이지 사이에 보관되어야 하는 상태를 저장 합니다. 보안에는 다소 취약 합니다.
2. 세션의 상태를 나타내는 HttpSessionstate는 서버 라운드 트립 간 또는 페이지간에 유지해야 하는 세션 관련 정보를 저장하기 위한 것입니다. 개별 세션에 따라 달라지는 짧게 사용하는 데이터 값을 저장 하는 경우에 이용 되며 보안이 중요하지 않은 경우엔 이용 합니다.
Web Form Page 상태 관리 -> 클라이언트 기반
페이지 저장 정보에 서버의 리소스를 사용 하지 않으며 보안기능이 최소화 되었으며 수핼 속도가 빠르지만 저장 하는 정보의 량이 제한적인 방법들 입니다.
1. ViewState : 원래 위치에 다시 보여질 정보를 위해 소량의 정보를 저장 하는 경우에 사용 합니다. 기존의 웹개발에서는 어래의 히든 필드, 쿼리문자열 등을 이용해서 계속 가지고 다녀야 하는 정보를 보관 했습니다.
2. Hidden Field : 의미는 ViewState와 다소 비슷합니다. 그러나 개발자가 일일이 코딩을 해주어야 합니다.
3. Cookie : 클라이언트의 하드디스크에 소량의 정보를 저장하기 위해 사용하며 보안이 용이 하지 않습니다.
4. QueryString : 한페이지에서 다른 페이지로 소량의 정보를 전달 시 이용 됩니다. 보안이 중요하지 않은 경우에 주로 이용 됩니다. 일일이 프로그래머의 코딩이 필요 합니다.
웹폼에서 전송 간에 상태를 유지 하기 위해서는 주로 ViewState를 통해 현재 웹폼의 상태를 저장 하여 폼을 전송 하거나 이벤트가 발생 하는 시점에 ViewState가 서버로 전송 됩니다. 서버에서는 이벤트를 처리 한 후 다시 클라이언트로 정보를 보낼 때 ViewState를 다시 전송 하며 Page 객체의 IsPostBack 속성을 통하여 확인이 가능 합니다. Web Control의 AutoPostBack 속성이 true이면 이벤트 발생시 즉시 PostBack 됩니다.
ViewState
ViewState를 사용하면 페이지를 원래 위치에 다시 게시할 때 라운드 트립 간 고유의 페이지 관련 값을 저장할 수 있습니다. 예를 들어, 응용 프로그램이 사용자별 정보(페이지에서 사용되지만 컨트롤의 일부일 필요는 없는 정보)를 유지하는 경우 이를 뷰 상태에 저장할 수 있습니다.
ViewState는 ASP.NET페이지에 의해 관리되는 Hidden컨트롤이라고 볼 수 있습니다.
// ViewState 속성에서 새 요소를 만들어 저장 합니다.
ViewState["name"] = "jclee";
// 해당 이름을 지정하여 요소의 값에 접근 합니다.
string sName;
sName =(string)ViewState["name"];
장점
- 서버 리소스 불필요(페이지 코드 내의 구조에 포함)
- 구현의 용이하며 페이지 및 컨트롤 상태 자동 보존(Cient에 보관)
단점
- 보안에 취약(웹페이지의 소스 보기로 보임, 데이터 훼손 가능성, 숨겨진 필드에 포함된 정보를 볼 수 있으므로 보안 문제가 발생 가능)
- 렌더링될 때 직렬화(serialize)과정을 거치기 때문에 SerializableAttribute가 적용되는 데이터 타입으로 제한
- ViewState는 페이지에 자체적으로 저장되므로 큰 값을 저장하면 사용자가 페이지를 표시하고 게시할 때 속도가 느려질 수 있습니다
ViewState의 정보는 내부적으로 System.Web.UI.StateBag 개체를 사용하여 이름/값을 갖는 형태로 저장 됩니다. ViewState의 기능은 StateBag 클래스로서 제공 되는 것이며 ASP.NET에서는 이를 읽어 해석 할 수 있는 것입니다. 만일 어떤 데이터가 PostBack 간에유지 되어야 한다면 ASP에서는 쿠키, 세션 등을 이용했지만 .NET에서는 StateBag을 주로 사용 합니다.
참고. fordeveloper2.tistory.com/7388?category=360959
UpdatePanel(업데이트패널) 이란??
- UpdatePanel은 웹에서 PostBack될 때 창이 깜빡이지 않고 새로고침 해주는 컨트롤이다.
- Button등을 눌렀을 때, 전체 page를 갱신하지 않고, page 내의 일정 부분만 갱신하는 기능이다.
(UpdatePanel 내의 값들만 PostBack되는건가?)
장점
1. Button postback에 의한 전체 page reload를 방지할수 있다.
2. 페이지 전체가 아닌 일정 부분만 reload 하기 때문에 속도가 빨라진다.
UpdatePanel의 속성
- UpdateMode : 언제 업데이트를 시킬거냐!
-> Always : 모든 이벤트에 대해 새로고침
-> Conditional : Trigger에서 지정한 컨트롤에서 이벤트가 일어날 때
- <asp:AsyncPostBackTrigger> : 지정 컨트롤(ControlID)에 이벤트가 발생했을때 실행
- <asp:PostBackTrigger> : 지정 컨트롤(ControlID)에 지정한 이벤트(EventName)가 발생했을때 실행
<asp:ScriptManager ID="scriptManager1" runat="server" />
<asp:Button runat="server" ID="EditButton" Text="수정"></asp:Button>
<asp:UpdatePanel ID="updatePanel1" runat="server" UpdateMode="Conditional">
<ContentTemplate>
<asp:GridView ID="gridView1" runat="server">
<!—그리드뷰 속성 지정-->
</asp:GridView>
</ContentTemplate>
<Triggers>
<!-UpdatePanel1 밖에있는 EditButton이 Click될때 UpdatePanel 발생->
<asp:AsyncPostBackTrigger ControlID="EditButton" EventName="Click" />
</Triggers>
</asp:UpdatePanel>
updatepanel 을 사용하기 위해서는 상단에 ScriptManager를 사용해줘야 합니다.
UpdatePanel 한 page 내에 여러개가 존재한다면,
Always 의 경우 Triggers 발생시 모든 UpdatePanel 이 갱신된다.
Conditional 의 경우 Triggers 발생시 해당 UpdatePanel 의 ContentTemplate 만 그 영향을 받는다.
따라서 왠만하면 Conditional 로 UpdateMode option 을 설정하기 바란다.-
Button과 같이 UpdatePanel 에서 event를 발생 시킬 부분
종류1. AsyncPostBackTrigger : postback 이 발생하지 않는 trigger 를 설정
종류2. PostBackTrigger : postback 이 발생하는 trigger 를 설정
Triggers 에 의해 지정된 Button은 UpdatePanel안에다 넣어도 되지만, 속도 향상을 위해 밖에 놓는게 좋다.
UpdatePanel 이 page내에 설정되어 있더라도 동일 page의 UpdatePanel 로 설정되지 않는 button을 click한 경우, 그 button 의 postback에 의하여 전체 page (UpdatePanel 포함) 가 갱신되니 주의해야한다.
20210408
Q. ClientIDMode="static" 이란?
javascript 상에서, $("#ObjectID") 형식으로 Original ID로 접근하기 위해서 쓰는 속성값
위와 같이 쓰지 않을 경우, $("#<%=ObjectID.ClientID%>") 으로 접근하면 된다.
'[CS] IT 용어 모음' 카테고리의 다른 글
| [React] 빠르게 정리하기 (0) | 2021.06.07 |
|---|---|
| SSL 인증서란? (0) | 2021.05.28 |
| 지식관리_방법론 (0) | 2021.03.26 |
| 지식관리_sql (0) | 2021.03.25 |
| [IT용어] CQRS[Command and Query Responsibility Segregation]과 이벤트 소싱[Event Sourcing]이란? (0) | 2020.11.04 |
최근댓글