Posted
Filed under .NET/ASP.NET

Hello. ASP.NET!!

그렇다. 오랫동안 기다렸다. 손가락이 날뛰고 싶어하는 것을 오랫동안 참고 견디게 한 여러분의 노고를 치하한다. 그러면 이제 개념적인 이야기들을 잠시 접고, 우리의 첫번째 ASP.NET을 바라보도록 하자. 이 간단한 하나의 예제에서 여러분은 웹 폼(Web Form)과 웹 서버 컨트롤, PostBack 그리고 이벤트 중심적인 프로그래밍 방법을 모두 만나볼 수 있을 것이다.

메모장을 열고 다음과 같은 코드를 작성하자.(아직은 Visual Studio.NET을 사용하기에 이르다)

<%@ Page language="c#"%>
<HTML>
    <Script runat="server">
    void btnSubmit_OnClick(Object sender, EventArgs e)
    {
        lblMsg.Text = "클릭!!!";
    }
    </Script>
    <body>
        <form runat="server">
            <asp:Label id="lblMsg" runat="server" /><br>
            <asp:Button id="btnSubmit" runat="server"
                    Text="Click!!!" OnClick="btnSubmit_OnClick" />
        </form>
    </body>
</HTML>

그리고, 이 페이지를 여러분의 가상 디렉터리에 Start.aspx 라는 이름으로 저장해보자. 때오는 TaeyoBook 라는 가상 디렉터리를 만들어 두었다. 만일, 가상 디렉터리가 무엇이고, 어떻게 만드는지를 모른다면 다음 강좌를 참고하도록 하라.

http://www.taeyo.pe.kr/lecture/1_beginner/aspbook6.htm

자. TaeyoBook 이라는 가상 디렉토리를 만들고, 그 안에 위의 파일을 Start.aspx 라는 이름으로 저장했다면, 이제 이 파일은 인터넷을 통해 공개가 되어진 것이다.(여러분의 IP주소가 고정 IP라면) 만일, 여러분이 사설 네트워크 망내에 들어있다면(대부분의 학원, 학교, 교육센터가 그러하다) 여러분의 ASP.NET 사이트는 외부인들은 구경해볼 수 없을 것이다. 하지만, 사설망안의 사람들은 여전히 가능하다.

대부분 아는 이야기겠지만, 개발자 자신이 자신의 서버에 존재하는 aspx 파일을 실행시키기 위해서라면 브라우저로 다음과 같이 URL을 요청하면 된다. 세 가지 중 어떤 방법이든지 사용해도 무관하지만, 일반적으로는 첫번째 방법을 많이 사용한다.

- http://localhost/TaeyoBook/Start.aspx
- http://서버이름/TaeyoBook/Start.aspx
- http://IP Address(아이피 주소)/TaeyoBook/Start.aspx

다음 화면은 이렇게 실행하였을 경우에 나타나는 결과화면이다. 왼쪽은 페이지가 로드되었을 경우의 화면이고, 버튼을 클릭하였을 경우의 화면은 우측과 같다.

좋다. 일단 동작했다는 점은 맘에 든다. 이번에는 브라우저의 결과화면에서 [보기] [소스 (C)]를 선택해서 결과 HTML은 어떻게 만들어졌는지 확인해 보자. 아마도 다음과 비슷할 것이다. (소스 중에는 <input  type="hidden" 컨트롤이 하나 있을텐데 그 안에 들어있는 값들은 때오의 것과 다를 수 있다)

<HTML>
    <body>
        <form name="_ctl0" method="post" action="Start.aspx" id="_ctl0">
            <input type="hidden" name="__VIEWSTATE"
                value="dDwtOTk1MjE0NDA4O3Q8O2w8aTwxPjs+O2w8dDw7bDxpPDE+
                Oz47bDx0PHA8cDxsPFRleHQ7PjtsPO2BtOumrSEhITs+Pjs+Ozs+Oz4+Oz4+
                Oz6H3gaYy7qY2B/L0EAGvSqLn3ak8w==" />

            <span id="lblMsg">클릭!!!</span><br>
            <input type="submit" name="btnSubmit" value="Click!!!" id="btnSubmit" />
        </form>
    </body>
</HTML>

다 되었다. 이제 뭐가 어떻게 된 것인지 설명을 듣는 것만이 남아있다. 그러나, 주의하라. 새로운 기술의 첫번째 예제를 이해하는 것은 매우 중요하다. 첫번째 예제를 어떻게 이해했느냐에 따라 이후의 모든 예제들을 같은 방식으로 이해하려 들 것이기 때문이다. 그런 놀라운 적응력을 여러분들은 보유하고 있다. 그렇기에 이번 예제를 제대로 이해하려는 노력이 필요하다.  

먼저, 원래의 aspx 의 소스를 라인별로 알아보자. 첫번째 라인의 소스는 다음과 같았다.

<%@ Page language="c#"%>

이 부분은 ASP.NET 페이지에서만 사용 가능한 @Page Directive 라는 지시자 구역이다. 반드시 <%@ Page 라는 것으로 시작해야 하며, 이 안에 여러가지 설정을 지정할 수 있다. 이 구역에 지정하는 설정은 ASP.NET 파서와 컴파일러에 의해 사용되어지며, Page 의 여러가지 특성을 정의하기 위해 사용된다. @Page 지시자내에 사용할 수 있는 여러가지 어트리뷰트들은 차후 하나씩 알아보게 될 것이다. 우리의 코드에서는 그 어트리뷰트중에서 language 라는 어트리뷰트를 사용하고 있는데, 이는 현재의 페이지에서 사용할 .NET 언어를 지정하는 특성이다. 우리는 현재의 ASP.NET 페이지에서 사용할 언어로 C#을 지정하고 있음을 알 수 있다.

소스의 다음부분은 <html>의 시작부분이며, 그 밑으로 다음과 같은 서버 사이드 스크립트 블럭이 나오고 있다.

    <Script runat="server">
    void btnSubmit_OnClick(Object sender, EventArgs e)
    {
        lblMsg.Text = "클릭!!!";
    }
    </Script>

서버에서 처리될 스크립트 블럭은 반드시 위처럼 runat="server" 라는 특성을 보유한 <Script> 코드로 작성되어야 한다. ASP.NET 코드의 절반은 runat= "server" 라고 말해도 과언이 아닐 정도로 runat= "server"라는 어트리뷰트는 중요하다.

스크립트 블럭내에서는 void btnSubmit_OnClick(Object sender, EventArgs e)라는 함수가 자리를 차지하고 있지만, 이 함수에 대한 설명은 잠시 미루자. 이 함수는 서버측에서 누군가가 호출을 할 경우에만 작동하는 함수이다. 아직은 그 누구도 이 함수를 부르지 않았으니, 실제로 누군가가 부르는 경우 그 때 이 함수를 확인해 보자.

이제 <body> 안으로 들어간다. 그 안에는 다음과 같은 폼의 코드가 있다.

<form runat="server">

폼 태그 안쪽으로 runat="Server" 라는 어트리뷰트가 설정되어져 있다. 이 설정은 매우 중요하다. 바로 이 runat= "Server"로 인해서 이 폼은 ASP.NET의 웹 폼(Web Form)이 되는 것이다. 두둥~~

잠시 시간이 정지한 듯 보였을 것이다. 이해한다. 웹 폼의 정체가 이토록 썰렁한 것이라는 사실을 알았을 때, ASP.NET의 새로운 프로그래밍 모델인 웹 폼의 정체가 단지 이것이라는 것을 알았을 때의 그 실망감.. 때오도 같은 기분을 느꼈었다. 그러나, 한편으로는 대단한 것이다. 단지 runat= "server"라는 어트리뷰트의 지정만으로 이 폼은 실제로 웹 폼으로써 동작하게 된다. 실제 운영에 필요한 하부구조는 ASP.NET이 준비해 놓은 것이다. 어쨋든 이렇게 웹 폼이 구성되어지면 우리 개발자들은 웹 폼 내부에 놓여질 서버 컨트롤들과 프로그래밍적으로 용이하게 작업할 수 있게 된다.

하나의 ASP.NET 페이지에는 오직 하나의 웹 폼만이 존재할 수 있다는 사실도 기억하자. 그리고, 모든 서버 컨트롤들은 반드시 웹 폼 구역안(<form runat="server"> </form>) 안에 존재해야만 한다. 그래야만 프로그래밍적으로 제어할 수 있다.

이제 폼 내부의 코드로 들어가 보자. 그 안에는 2 개의 ASP.NET Web Control 들이 존재하고 있다. 처음보는 이름의 <asp:Label>과 <asp:Button> 은 그 명쾌한 이름으로 인해 컨트롤들이 ASP.NET 에서 새로이 제공하는 컨트롤이라는 것을 느낄 수 있게 하며, 동시에 각각의 컨트롤이 Label, Button 컨트롤이라는 것을 알 수 있게 하고 있다.

<asp:Label id="lblMsg" runat="server" />

Label 컨트롤은 단지 문자열의 값을 디스플레이하는 역할을 하는 단순한 기능의 컨트롤이다. 이 컨트롤은 서버 컨트롤로 사용할 것이기에 태그 안의 어트리뷰트로 반드시 runat= "server"를 설정해주어야 한다. 그리고, 서버에서 프로그래밍적으로 이 컨트롤의 여러 속성들을 접근하기 위해서 id 를 부여해야 한다. 아이디는 웹 폼내에서는 고유한 값을 가져야 하며, 여기서는 Label의 약어인 lbl을 접두어로 사용하여 lblMsg 라고 그 값을 주었다.

현재 우리의 ASP.NET 코드상에서는 <asp:Label > 컨트롤이지만, 이 코드가 컴파일되고 실행되서 결과물이 만들어질 때에 이 코드는 <span> 태그로 바뀌게 된다. 다음은 이 Label 컨트롤의 코드가 클라이언트에게 전달될 경우에 생성되는 결과 HTML 이다.

<span id="lblMsg"></span>

     서버 컨트롤은 서버에서만 인식되는 컨트롤이다.

서버 컨트롤은 서버에서만 인식되는 컨트롤이다. 클라이언트는 서버에 그러한 컨트롤이 있는지에 대해서는 전혀 알지 못한다. 또한, 클라이언트에서는 서버측의 컨트롤에 접근할 수도 없다. 우리가 작성한 모든 코드는 서버에서 실행시에 사용되는 컨트롤들이다. 클라이언트는 단지 자신이 받아 볼 결과에만 관심이 있다. 다시 말해서, 클라이언트에게는 원래의 aspx 소스를 훔쳐볼 방법이 없다.

그 다음 컨트롤은 Button 컨트롤이다. 마찬가지로 반드시 runat= "server" 라는 부분을 지정해 주어야 하며, id 값도 부여해야 한다. 소스에서는 id를 btnSubmit 라고 지정하였다. 그리고, Text 속성의 값을 지정하고 있다. Text 속성은 버튼이 화면에 출력될 경우에 버튼에 쓰여질 텍스트 문자를 나타낸다. 소스에서는 "Click!!!" 이라고 지정하고 있으며, 결과화면에서 그러한 텍스트를 가진 버튼을 우리는 볼 수 있게 될 것이다. 그리고, OnClick 라는 것에 btnSubmit_OnClick 이라는 값을 지정하고 있는 것을 볼 수 있다.

<asp:Button id="btnSubmit" runat="server" 
        Text="Click!!!" OnClick="btnSubmit_OnClick" />

이것이 바로 웹 폼, 서버 컨트롤들의 이벤트 지정이다. 컨트롤들이 지원하는 이벤트들이 컨트롤들마다 조금씩 다르기는 하지만 대부분의 컨트롤이 OnClick 이라는 이벤트를 지원한다. Button 컨트롤도 이 이벤트를 지원하는데, 이는 버튼이 클라이언트에 의해 클릭되었을 경우 발생한다. (정확히 말하자면, 버튼이 클릭되었을 경우, 서버로 폼을 서브밋하고, 다른 여러가지 기본 처리 후에, 버튼의 클릭 이벤트도 수행을 한다)그리고, OnClick 에 지정된 문자열과 같은 서버측의 함수를 찾아서 그 함수를 수행한다. 만일, 지정된 이름의 함수가 없다면 에러가 발생할 것이다. 그리고, 함수 이름의 대,소문자의 지정이 틀려도 에러가 발생할 것이다. C# 이라는 언어는 문자의 대. 소문자를 구별하는 언어이다. 즉, "a" 와 "A"를 다르게 생각한다는 것이다. 그러므로, "함수를 찾을 수 없습니다."와 같은 에러는 마주하게 되면 스펠링의 대,소문자가 틀리지는 않은지를 검사하도록 하라.

그리고, 이 컨트롤의 소스(태그)를 잘 보면 태그가 닫히기 직전에 / 라는 문자를 사용하고 있는 것을 볼 수 있다. 이는 태그가 닫는 태그(</asp:Button> 과 같은)를 사용하지 않을 경우 반드시 넣어주어야 하는 문자이다. /를 사용하면 닫는 태그를 쓰는 것과 같다고 볼 수 있다. 서버 컨트롤들은 반드시 이렇게 태그의 닫힘을 명확히 지정해 주어야 한다. 그렇게 하지 않으면 제대로 동작하지 않는다.(에러가 발생할 것이다)

또한, Button 컨트롤도 현재 우리의 ASP.NET 코드상에서는 <asp:Button> 컨트롤이지만, 이 코드가 컴파일되고 실행되서 결과물이 만들어질 때에 이 코드는 <input type="submit"> 태그로 바뀌게 된다. 다음은 이 Button 컨트롤의 코드가 클라이언트에게 전달될 경우에 생성되는 결과 HTML 이다.

<input type="submit" name="btnSubmit" value="Click!!!" id="btnSubmit" />

자. 이제 ASP.NET 페이지가 어떻게 구성되어져 있는지 간략히 알아보았다. 자. 그럼 이제 좀 더 구체적으로 알아보자. 페이지가 실행될 경우, 그리고 페이지에서 버튼이 클릭되는 이벤트가 발생할 경우 어떤 일들이 추가적으로 일어나는지를 말이다.

     클라이언트측의 버튼 클릭!! 서버측의 함수가 반응???

버튼이 클릭되었을 경우에 위의 설명대로라면 btnSubmit_OnClick 이벤트 함수가 처리되겠지만, 잘 보면 버튼을 클릭하는 것은 클라이언트 측의 행동이고, btnSubmit_OnClick 함수는 서버측에 있다. 클라이언트측에서 서버측의 함수를 호출할 방법은 사실상 없다. HTTP 라는 프로토콜은 연결이 유지되는 환경이 아니기 때문이다. 사용자가 결과물을 브라우저로 확인하고 있을 당시에 서버와의 연결은 이미 끊긴 상태이고, 인터넷은 잠시 끊겨져 있는 상태라는 것을 기억하라. 그것이 웹이라는 환경의 특성이다. 그럼에도, 이와 같은 방법이 가능한 것은 클라이언트가 버튼을 클릭할 경우에 무조건 폼이 서버로 서브밋되기 때문이다. 폼의 모든 데이터들이 서브밋이 되어지며, 동시에 현재 서버측의 btnSubmit_OnClick 라는 이벤트 함수를 호출하였다라는 정보도 같이 서버로 전송되어진다. 서버에서는 현재의 aspx 페이지를 다시금 생성하면서 추가적으로 btnSubmit_OnClick 라는 함수도 실행한다. 대략 이러한 식으로 페이지가 동작한다는 사실을 잠시 알아두기 바란다. 곧 구체적인 실행의 흐름과정을 알아보겠지만, 먼저 살며시 알아두는 것도 이해에 도움이 되리라 생각한다.

이제 Start.aspx 페이지의 첫 페이지가 로드되고, 사용자가 버튼을 클릭할 경우를 알아보자. 위의 참고에서 이야기했듯이 버튼이 클릭될 경우에는 무조건 웹 폼은 서버로 서브밋을 시작한다. 즉, 포스트백이 발생한다는 것이다. 별다른 제약을 두지 않는 한 기본적으로 웹 폼내에 존재하는 모든 버튼 서버 컨트롤들은 클릭시 웹 폼을 포스트백하게 된다. 단, 자신의 페이지로 폼을 서브밋하면서(즉, 포스트백) 현재 btnSubmit_OnClick 이라는 이벤트도 발생하였다라는 정보를 같이 넘긴다.

aspx 페이지는 사용자가 페이지를 요청하던, 버튼을 클릭하여 포스트백이 일어나던 매번 페이지의 요청에 따라 동적으로 결과물을 처음부터 다시 생성하기 시작한다. 버튼이 클릭되지 않은 첫 페이지의 로드시에는 btnSubmit_OnClick 이라는 함수는 실행되지 않은 채 결과 페이지가 생성되게 되지만, 버튼이 클릭되어 btnSubmit_OnClick 이라는 함수를 요청하게 되면, 결과 페이지가 생성되어지는 와중에 btnSubmit_OnClick 이라는 함수도 실행되어지게 되고, 그 결과를 포함한 결과물이 생성되어진다.

     잠시만!!

지금은 btnSubmit_OnClick라는 함수의 인자로 왜 (Object sender, EventArgs e)라는 것을 사용하고 있는지에 대해서는 잠시 무시하도록 하자. 곧 그 부분에 대한 자세한 설명이 뒤따를 것이다.

   void btnSubmit_OnClick(Object sender, EventArgs e)
    {
        lblMsg.Text = "클릭!!!";
    }

위처럼 btnSubmit_OnClick 이라는 함수안의 코드는 서버측에서 실행되어지면 서버측에서 프로그래밍적으로 Label 서버 컨트롤로 접근하여 lblMsg 라는 컨트롤의 Text 값을 "클릭!!!" 으로 설정하게 된다. 그리고, 그 결과에 의한 HTML을 다시금 동적으로 구성하게 된다. 해서, 버튼을 클릭했을 경우에는 결과화면으로써 다음과 같이 Label 컨트롤에 "클릭!!!" 이라는 출력문자가 포함된 것을 보게 되는 것이다.

 

다시 한번 강조하는 데, <Script runat="server"> 라는 서버측 스크립트 블럭은 클라이언트는 전혀 볼 수 없는 구역이며, 오로지 서버측 개발자만이 볼 수 있는 구역이다. 또한, ASP.NET 에 의해 해석되고, 실행되는 구역이다. 지금 브라우저에 의해 결과화면을 보고 있다면, 그 결과화면에서 HTML 소스를 보도록 하자. 클라이언트에게 전송된 결과 HTML 에서는 서버측의 코드가 어떻게 구성되어져 있는지 알 수 있을만한 코드는 단 한줄도 없을 것이다.

그렇다. 머리가 아프다. 만일, 여러분이 이전에 웹 프로그래밍을 접해본 적이 없다면, 이것은 더더욱 여러분의 머리를 죄어올 것이다. 게다가 만일 여러분이 이전에 C/S 프로그래밍에 익숙해져 있는 개발자라면 어쩌면 처음 ASP.NET을 접하는 이들보다 더욱 머리가 아플 수도 있다. 그래서 습관이라는 것이 무서운 것이다.

더이상 여러분의 머리를 아프게 하지 말자. 그런 의미에서 이 전체적인 흐름을 다시 한번 친절한 그림과 함께 일단 정리해 보도록 하자. 이것을 이해하는 것은 매우 중요하다. 물론, 이미 ASP 를 중급정도 다룰 수 있는 독자가 있다면 그리 어렵지 않게 받아들여질 수 있는 이야기일 것이지만, 그들은 더 잘 알고 있을 것이다. 이러한 기본적인 개념을 이해하는 것이 얼마나 중요한 것인지 말이다.

다음 그림을 보자. 이것은 우리가 작성한 Start.aspx 의 원본 소스이다.

- 이 소스는 서버에 존재하고 있는 코드이며, 사용자는 이 코드를 볼 수가 없다.
- <asp:Label> 이라는 컨트롤을 서버의 처리에 의해 <span> 태그로 둔갑하게 된다.
- <asp:Button> 이라는 컨트롤은 서버의 처리에 의해 <input type="submit"> 로 바뀌게 된다.

그렇게 바뀌어서 다음과 같은 HTML이 만들어지고, 이 HTML이 클라이언트의 브라우저에게 넘겨진다.

이 코드는 생성된 클라이언트 코드이다. 폼 태그쪽을 보면 action (즉, 폼이 서브밋될 서버 페이지명)이 자기 자신 페이지로 지정되어져 있고, 폼의 아이디도 서버에 의해 동적으로 부여되어져 있다.

그리고, hidden 컨트롤이 하나 있는데, 그 이름은 _VIEWSTATE 이고, 값으로는 알아보기 힘든 값들이 들어있다. 이것은 서버측에서 여러 필요한 정보들을 base64 방식으로 인코딩하여 숨겨두는 방법이라고만 알아두자. 나중에 자세히 배우게 될 것이다.

물론, 여러분이 브라우저로 보게 되는 결과는 위의 코드가 아닌 다음과 같은 화면일 것이다. 하지만, 이 화면이 바로 HTML로는 위와 같다는 사실은 알고 있을 것이라 생각한다.

서버측의 코드와 클라이언트측의 결과를 비교해 보니 조금은 이해가 쉽다. 그렇지 않은가? 만일, 이해가 안가는 부분이 있다면 가장 좋은 방법은 일단은 그냥 외우는 방법이다. 프로그래밍은 많은 예제와 실습을 통해서 여러분의 것이 되어지기에, 지금의 설명이 피부에 와닿지 않을 수 있다. 그럴지라도 조급하지 말자. 곧 여러분의 것이 될 것이다.

자. 이 상태에서 클라이언트는 버튼을 클릭한다. 버튼을 클릭하는 순간, 폼은 서브밋되고, Start.aspx 는 서버로 페이지를 다시 구성해달라는 재요청을 하게 된다. 그 요청에 의해 클라이언트가 받아보게 되는 결과는 다음과 같은 HTML 이다.

_VIEWSTATE 라는 컨트롤의 값들이 많이 늘어난 것을 볼 수 있으며, <span> 태그 안에는 "클릭!!!" 이라는 문자열이 추가되어져 있다. 버튼이 클릭되어, 서버에서 추가적으로 실행된 함수(btnSubmit_OnClick)의 결과만이 추가되어진 것이다. _VIEWSTATE의 값이 늘어난 이유에 대해서는 곧 알아보게 될 것이다. 그리고,다음 그림은 이 HTML가 사용자 브라우저에 보여질 경우의 화면이다.

또한, 다음 그림을 통해서 클라이언트와 서버간의 흐름을 다시 한번 정리해 보자.



그림이 조금 작아서 보기에는 그렇겠지만, 이것은 간단하게나마 전체적인 흐름을 보여주고 있는 그림이다. 사실, 보여지는 그림이 ASP.NET이 동작하는 방식이라고 이야기하기에는 많은 부분을 생략하고 있긴 하지만, 처음 예제를 이해하는 것이기에 일단은 이정도로 이해해도 그리 나쁘지 않아보인다. 구체적인 ASP.NET의 처리방식, 이벤트 로딩순서등에 대해서는 계속해서 보강해 가며 알아볼 것이다.

이제 어느 정도 정리가 되어진 듯 하다. 부디 이것이 필자만의 생각은 아니기를 바라는 마음으로 btnSubmit_OnClick 이라는 이벤트 함수에 대해서 조금 더 알아보도록 하자.

서버 사이드 스크립트 블럭내에서는 void btnSubmit_OnClick(Object sender, EventArgs e)라는 함수가 자리를 차지하고 있다. 왜 이런 이름으로 함수를 만들어야 하는지, 함수에서 사용하는 두개의 인자는 무엇인지 알지 못한 채 그렇게 사용하고 있다. 미리 언급하자면 반드시 함수의 인자로는 첫번째 Object 라는 타입의 인자를 사용해야 하며, 두번째 인자로는 EventArgs 타입의 인자를 사용해야 한다.

함수의 시작은 void 로 시작하고 있는데, 이 의미는 이 함수에 의해 리턴되는 값은 아무 것도 없다는 의미이다. 리턴할 값이 없는, 자신에게 주어진 처리만 하고 작업을 마무리하는 함수는 이처럼 앞에 반드시 void 라는 키워드를 사용해 주어야 한다. 만일, 작업 후 어떤 Integer 값을 리턴할 함수가 있다면 void 대신 int 를 사용해 주어야 하고, 어떤 문자열 값을 리턴할 함수가 있다면 void 대신 string을 사용해 주어야 한다.

btnSubmit_OnClick 이라는 함수의 이름은 임의적이다. 즉, 우리 마음대로 지정할 수 있다는 것이다. 이 함수는 코드 중에 버튼 컨트롤이 클릭할 경우에 호출되게 할 함수이기에 이름을 btnSubmit_OnClick 라고 주었다. btnSubmit은 버튼 컨트롤의 아이디로 지정된 값이고, OnClick 이벤트가 발생시 처리될 함수라는 의미로 말이다.

사실, 이러한 함수의 이름은 관례적으로 '컨트롤명_이벤트명'으로 주고는 한다. 반드시 그렇게 할 이유는 없지만 많은 개발자들이 그런 방식으로 명명하고는 하기에, 가급적 따르는 것이 좋을 것이다. 경험에 기반한 이러한 작은 규칙들은 따르는 것은 눈에 보이지 않는 잇점이 있는 편이고, 적어도 손해는 주지 않는다.

그 다음 함수에서 사용하는 인자들을 보도록 하자. (Object sender, EventArgs e) 라고 되어져 있다. 이것은 지켜야 할 룰이다. 첫번째 인자로는 반드시 Object 형의 인자를 지정해 주어야 하고, 두번째 인자로는 반드시 EventArgs 라는 형의 인자를 지정해 주어야 한다.  이 인자들은 일괄적으로 모든 이벤트들에서 사용되어진다. 누가 그러한 인자값을 알려주는가? ASP.NET이 그러한 것을 우리에게 넘겨준다. 개체 변수의 이름은 여러분이 지정하기 나름이다. (Object sender, EventArgs e) 라는 부분을 다음처럼 바꾸어도 아무런 문제는 없다

(Object myobject, EventArgs myEvent)

변수의 타입만 제대로 지정해 주면 된다. 첫번째 인자인 Object로는 현재 이벤트를 발생시킨 그 객체 자체에 대한 참조가 넘어온다. 두번째 인자로는 이벤트 데이터를 가지고 있는 개체 클래스가 넘어온다. 중요한 것은 첫번째 인자로 우리가 이벤트에 사용한 컨트롤은 Button 인데, 인자의 데이터형은 Button이 아니라 Object 형이라는 사실이다. 나중에 이야기하겠지만 이것은 모든 컨트롤들에게 범용적으로 사용하기 위해서 Object 로 넘겨져 오는 것이다. 만일, Object 라는 통일된 데이터 타입을 사용하지 않는다면, 버튼의 이벤트의 경우에는 (Object sender, EventArgs e) 라는 것이

(Button sender, EventArgs e)

이 되어야 할 것이고, 텍스트박스의 경우는

(TextBox sender, EventArgs e)

가 되어야 할 것이다. 이것은 그다지 좋은 선택이 아니다. 그렇기에 ASP.NET 은 모든 컨트롤들을 Object 라는 형으로 개체 참조를 형변환(Casting)하여 첫번째 인자로 넘겨주는 것이다. (Object sender, EventArgs e) 라고 말이다.

개발자인 여러분들은 첫번째 인자로 Object 가 넘어온다고 해도 실은 이 이벤트를 일으킨 컨트롤이 누구인지 알고 있다. 그러므로, 함수 내의 소스에서 이 Object를 Button으로 다시금 변환해서 사용할 수 있다.

그리고, 사실 이렇게 Object 형으로 형변환 가능한 것은 Object 형이 모든 컨트롤들의 원조 클래스이기 때문이다.  구체적인 내용들에 대해서는 나중에 더욱 자세히 알아볼 것이다. 지금은 가벼운 이야기를 해야하는 시간인데, 조금은 깊게 들어왔다. 죄송하게 생각한다. 좋다. 일단은 여기까지만 기억하자. 이해가 전혀 가지 않는다고 해도 괜찮다. 나중에 여러가지 예제들을 통해서 여러분은 충분히 이해하게 될 것이다. 알려는 마음만 가진다면 어려울 것은 전혀 없다. 다시 한번 이야기하지만, 여러분은 아직 여러분의 두뇌를 과소평가하고 있다.

    두번째 인자가 언제나 EventArgs 타입이라굽쇼? 안 그런 것도 있던데??

물론, 이벤트를 발생시킨 컨트롤에 따라 두번째 인자의 형은 바뀔 수도 있다. 그렇다면 때오가 이야기한 일괄적으로 (Object sender, EventArgs e) 가 사용된다는 말은 틀린 말일 것이다. 하지만, 컨트롤에 따라 틀려지는 두번째 이벤트 형의 부모 클래스는 사실 EventArgs 이다. 그렇기에 위에서는 넓은 의미에서 일괄적으로 (Object sender, EventArgs e) 와 같은 인자가 사용된다고 이야기한 것이다.

인자부분을 정리하자면, 무조건 일반적인 경우는 (Object sender, EventArgs e) 를 사용한다고 기억해 두자. 이것은 ASP.NET에 의해 어느정도는 고정되어져 있다고 생각하자. (하지만, 기쁘게도 여러분은 이러한 인자를 외울 필요가 없다. 이후에 VS.NET 을 사용해보면 알겠지만, 모든 이러한 코드들은 VS.NET이 자동으로 우리를 대신하여 만들어 준다.)

자. 이제 함수 내부를 이야기할 시간이다. 함수의 안에는 다음과 같은 한줄짜리 코드가 존재한다.

lblMsg.Text = "클릭!!!";

이것은 lblMsg 라는 id를 가진 서버 컨트롤(코드상의 Label 컨트롤)의 Text 속성의 값을 "클릭!!!" 이라는 값으로 설정하라는 코드이다. 그리고, 함수는 닫힌다. 그래서, 여러분은 결과화면에서 "클릭!!!" 이라는 값이 출력되는 것을 볼 수 있었던 것이다.

자. 이 시점. 여러분은 한가지 의문이 들 수 있다. 버튼이 클릭될 경우, 폼은 자기 자신 페이지로 전송이 되고, 버튼이 클릭하여 발생한 이벤트인 btnSubmit_OnClick 이라는 함수가 실행되어진다는 것은 알았는데 그런데, 만일 폼을 자기 자신 페이지가 아닌 다른 페이지로 전송한다면? 즉, 폼 태그 부분을 다음처럼 수정하여 action 을 다른 페이지로 지정한다면?

<form runat="server" action="otherPage.aspx">

이렇다면, 버튼이 클릭될 경우, 폼은 otherPage.aspx 로 전송되어질 것이고, otherPage.aspx 페이지의 btnSubmit_OnClick 함수가 실행되어지는 것인가? 만일, otherPage.aspx 페이지에 btnSubmit_OnClick 이라는 함수가 없다면? 이렇게 되면 상당히 많은 문제가 발생한다. 이것은 난감하지 않을 수 없다.

ASP.NET은 이러한 부분도 해결하고 있는데, 그것은 개발자가 폼의 action을 바꾸어도 그 내용은 무시해버리고, 자기 자신 페이지로 포스트백 하도록 한다는 사실이다. 그래서, 이전에 필자는 ASP.NET의 흐름은 다음 그림과 같다고 강조했던 것이다.

기억하자. 웹 폼의 action을 개발자가 바꾸어도 ASP.NET은 그 경로를 자기자신 페이지로 강제한다는 것을 말이다.

호오.. 매우 긴 첫번째 예제였다. 그 어떠한 책도 시작하는 예제, 일명 "Hello" 예제를 가지고 이렇게 길게 끈 적은 없었을 것이다. 필자가 이렇게 많은 지면을 할애하여 이 부분을 설명한 데에는 그만한 이유가 있다. 이 작은 예제에 대한 이해가 앞으로의 만날 수 많은 예제들을 이해하는 데에 큰 기반이 되어줄 것이기 때문이다. 기능적인 이해 뿐 아니라, 코드에 의한 기능을 넘어선 뒷단의 논리 흐름의 이해까지도 고려하며 프로그래밍을 할 수 있게 할 것이기 때문이다.

좋다. 모든 것을 이해했던, 일부만을 이해했던, 아예 이해를 하지 못했던 어쨋든 여러분의 머리속에는 어느 정도의 기반이 준비가 되어져 있다. 이제, 쉬운 길을 보여주도록 하겠다.

같은 예제를 VS.NET(Visual Studio.NET)으로 작성하는 예를 말이다. 여러분이 관심을 가져야 할 것은 코드가 아니라 흐름임을 기억하고, Start.aspx 를 VS.NET으로 만들어 보자.


출처 : Taeyo.pe.kr
2007/08/06 11:28 2007/08/06 11:28
Posted
Filed under .NET/ASP.NET

.NET Execution Model

그렇다면 먼저 .NET 코드의 실행 모델을 그림으로 우선 만나보자.

위의 그림은 코드 실행의 구조를 아주 잘 나타내 주고 있다. 모든 .NET 언어로 작성된 소스 코드는 언어에 따르는 컴파일러를 통해서 MSIL 이라는 중간언어로 만들어 진다. 여기까지를 우리는 Compilation 단계라고 부른다. 이 단계의 결과물로는 중간 언어인 MSIL과 그 중간 언어에 대한 여러가지 정보를 가지고 있는 MetaData 라는 것이 생긴다. 중간 언어로 존재한다고 하더라도 우리 눈에 보여지는 이 결과 파일의 확장자는 DLL 이나 EXE 이다. 조심할 것은 이 확장자로 인해 이 파일이 라이브러리 파일이거나 실행파일이라고 착각하는 것이다. 안타깝게도 이들은 단지 그러한 확장자를 가진 중간언어이다.  CLR의 도움 없이는 아무것도 할 수 없는...

이러한 중간적인 상태로 존재하던 파일들이 이제 실행시점에 들어가게 되면 CLR 내의 JIT(Jitter 라고도 호칭함)라는 컴파일러에 의해 다시금 컴파일되고, 그 결과 실제로 실행가능한 플랫폼 기반의 Native Code 가 생성되어지게 된다. 여기까지의 단계를 Execution 단계라고 부른다.

모든 .NET 코드들은 위와 같은 단계를 거쳐서 실행을 하게 된다. .NET 이전의 Windows 시절의 방식과 비교했을 경우에 오히려 거추장스러우면서, 성능의 저하를 가져올 것처럼 느껴지는 단계들이 존재한다고 보일 수도 있다. 하지만, 자못 그렇게 보일 수 있는 단계들이 .NET으로 하여금 여러가지의 막대한 잇점을 갖게 하는데, 그것은 언어 독립성, 교차 언어의 상속가능, 플랫폼 기반의 최적화된 코드의 생성등이다. 어떠한 점이 잇점인지, 그 외에 더 얼마나 많은 잇점을 제공해주기에 이러한 실행구조를 .NET이 갖는지등에 대한 더욱 구체적인 이야기들은 MSDN의 .NET Framework의 소개나, 여러 .NET 관련 언어 서적을 통해서 얻을 수 있을 것이다. .NET 구성과 관계된 서적을 한권쯤은 꼭 정독하여 Microsoft가 .NET이라는 것을 얼마나 면밀히 계획했는지 살며시 들여다보는 것도 개발에 도움이 되리라 생각한다. (태오의 개인적인 추천서적으로는 2002년 4월에 번역 출간되는 Wrox의 PROFESSIONAL .NET FRAMEWORK을 추천한다. 물론, Ms Press의 것은 말할 것도 없다.)

.NET의 실행 모델은 사실상 Java 것과도 비슷하다고도 볼 수 있지만, 진화된 환경이란 이전 환경의 좋은 점들을 모두 추출하여, 그 것을 기반으로 발전시켜 나가는 것이라고 볼 때, .NET은 Java의 진화 발전형이라고 볼 수도 있을 것이다.

위의 실행 모델은 ASP.NET 뿐 아니라 모든 .NET의 코드들에 적용된다. 사실 ASP.NET의 경우는 위의 기본적인 모델을 따르면서 약간은 자신만의 단계들이 존재하고 있지만, 여전히 기본은 위의 모델이다.

위에서 Execution 단계를 관할하는 것이 바로 CLR 이다. CLR은 누누히 강조했지만, 위처럼 코드의 실행을 관리하는 역할을 한다. 그래서 CLR이 .NET 프레임워크의 가장 중요한 부분중의 하나라고 이야기 했던 것이다. (사실, .NET 프레임워크의 가장 중요한 다른 하나는 .NET 프레임워크 클래스 라이브러리이지만, 이 둘이 바로 .NET 프레임워크 이니...  CLR이 가장 중요하네~ 라는 식의 말은 강조를 위한 말장난같아 보일 수 있음을 인정한다. ^^)

실행 모델의 간단한 구성에 대해서 알아보았다. 그러나, 역시 뭔가 부족한 느낌이 있다. 그렇다면, 조금 더 세분화하여 실행모델을 구체적으로 살펴보도록 하자. 이 실행 모델을 이해하는 것은 매우 중요하다. 지금 이를 확인하지 않고 넘어갈 수는 있겠지만, 그렇게 되면 차후에 쓸쓸히, 아주 외롭게 남들은 중급적인 내용을 공부할 때, 자신만이 다시 이 자리로 돌아와서 실행 모델을 확인하게 될지도 모른다.

다음은 구체적인 Execution Model 이다.

 

어떤가? 이전 그림보다는 구체적이다.

그럼 그림을 하나하나 살펴보도록 하자. 흐름은 좌측 상단에서부터 시작하여 우측 하단으로 흐른다. 먼저 소스코드가 컴파일러와 메타 데이터 엔진에 의해 중간언어인 IL 과 또한 그 IL을 설명하는 메타 데이터로 구성되는 것을 볼 수가 있다. 그렇게 구성되어진 MSIL 은 그 파일과 연결된 다른 어셈블리들이 있을 경우, Linker 라는 것을 통해서, 하나의 EXE 나 DLL 로 만들어지게 되며, 이것이 이전에 말했던 관리 코드이다.

좋다. 여기까지가 컴파일 단계이다.

   어셈블리 (Assembly)란?

이는 컴파일된 관리 코드들이 저장되는 단위로써, 기존의 EXE 나 DLL 파일과 비슷하다고 볼 수 있지만, 어셈블리는 이전 EXE, DLL 과는 다르게 자신을 설명하는 메타 데이터를 가지고 있다. 이것이 중요한 차이점이다.

그리고, 하나의 EXE 나 DLL 로써 존재하고 있던 관리 코드들은 실행시가 되면 이제 CLR에 의해서 실행 파일이 되기 위한 다시 한번의 컴파일 과정을 거치기 위한 준비들을 하는데, 그 첫번째가 바로 CLR의 Class Loader 에 의해 클래스의 레이아웃이 잡히고, 로드되는 단계이다. 이 때, Base Class Library 로부터 여러가지 기본적인 클래스들도 같이 로드하는 것을 볼 수 있다.  이렇게 클래스가 로드되면 그것을 Jitter('지터'라고 발음함) 로 컴파일을 하게 되고 그로인해 원시코드는 탄생하게 되는 것이다. 그리고, 즉시 실행을 시작한다. 여기까지가 실행 단계이다.

이제 여러분은 .NET 언어로 제작한 특정 파일이 두번의 컴파일 단계를 거친다는 사실과, 전체적인 실행 구조에 대해서 알아보았다. 이 지식이 지금 당장 여러분에게 눈에 보이는 어떤 도움이 될 것으로 기대되지는 않지만, 차후 분명 도움이 될 지식임은 자명하다. 이해가 가지 않는다고 하더라도 가급적 기억은 하고 있기를 바란다.


ASP.NET Execution Model

자. 이제 ASP.NET으로 고개를 돌려보자. 그렇다고 지금 ASP.NET 코드를 작성해 보자는 의미는 아니다. 아직 우리는 ASP.NET 이라는 새로운 기술을 제대로 시작하기 위한 준비를 하고 있는 단계에 있다. 그렇다면, ASP.NET의 어떠한 것을 이야기하고자 하는 것인가? 바로 ASP.NET의 실행 모델이다.

다음 그림은 ASP.NET의 실행 구조를 나타내고 있는 그림이다.

 

호오. 좀 복잡하게 보인다. 하지만, 이전 .NET의 실행 모델을 머리속에 두고 생각해 보면, 이 흐름이 그리 어렵게 느껴지지 않을 것이다. 그럼 이전 지식들을 뇌의 메모리에 올린 다음에 태오와 같이 이 흐름에 대해서 알아보도록 하자.

먼저, 클라이언트는 서버로 특정 aspx (ASP.NET 페이지)를 호출한다.  taeyo.aspx 라는 페이지를 달라는 클라이언트의 호출을 받은 웹 서버는 이 파일을 찾고, 이 파일의 확장자를 확인한다.

만일, 이 파일의 확장자가 htm 이라면 서버는 찾은 파일을 클라이언트에게 넘겨주기만 하는 역할일 뿐이겠지만, 파일의 확장자가 aspx 라는 것을 확인하면, 서버는 이 확장자와 연결되어져 있는 DLL (ASP.NET) 에게 이 파일의 처리를 의뢰한다. (ASP 때 그러하였던 것처럼 말이다)

ASP.NET은 이 파일을 받아서 일단 파싱하는 작업을 한다. 라인 단위의 파싱작업을 끝낸 다음에 이 파일은 서버에 의해서 일단 컴파일이 되어진다. 그림으로는 현재 우측 상단까지 진행되어 온 것이다. 컴파일이 되어지면 MSIL과 MetaData로 만들어지고, 이는 관리 코드인 Assembly IL 이라는 것으로 만들어 진다. 확장자는 DLL 이나 EXE 가 될 것이다. 나중에 실제 이렇게 만들어져 있는 어셈블리 IL을 확인해 볼 것이다.

일단, 관리 코드로 만들어진 것들은 어셈블리 캐쉬라는 공간에 쌓여지게 된다. 이 부분은 기존의 .NET 실행 모델과는 조금 다른데, 이것은 ASP.NET 이라는 웹 프로그래밍의 특성으로 인해 제공되는 것이다. 즉, 일단 컴파일되어진 aspx 페이지들은 그 중간완성품을 캐쉬에 저장해 놓고, 이후 여러 사용자들이 같은 aspx 페이지를 요청할 경우, 새롭게 컴파일을 해서 IL을 만들어 내는 것이 아니라, 이 캐쉬에 이미 존재하는 IL을 재사용하게 하는 것이다. 이로 인해 상당한 속도의 증가효과를 얻어낼 수 있다는 감이 마구 올 것이다.

일단, 어셈블리 캐쉬에 올라와 있는 IL 들은 요청에 대한 응답을 기다리고 있는 사용자들에게 결과물을 건네어주어야 하기에 실행을 실시한다. 캐쉬에 있던 IL 은 메모리로 올라가게 되고, 이것은 CLR의 Jitter 에 의해 다시 한번 컴파일되어지며, 그 결과 만들어지는 결과물들(대부분의 경우 동적으로 생성된 HTML)을 클라이언트의 브라우저에게 넘겨주게 되는 것이다.

중요한 것은 사용자들은 서버에서 어떠한 일이 일어나는지 모른다는 것이다. 여러분도 이 강의를 듣기전에는 전혀 알지 못했다. (물론, 예습을 통해서 알고 있었던 분도 있을 것이기는 하다) 사용자는 단지 aspx 페이지를 요청했고, 그 요청에 의해 결과로 HTML을 돌려받았다. 그게 전부이다. 사용자는 단순하다. 사용자가 요청한 결과만 주면, 그것으로 충분히 만족한다.

하지만, 이러한 흐름을 다루어야 할 여러분, 개발자들은 다르다. 서버측에서 발생하는 모든 흐름에 대해 이해하고 있어야만 하고, 그 흐름에 맞추어 프로그램을 작성해야만 한다. 이것이 ASP.NET의 실행구조를 이해해야만 하는 이유이며, .NET 이라는 기술을 이해해야만 하는 이유이다.

자. 정리해 보자. 위의 그림은 어떤 특정 페이지를 사용자가 처음 요청했을 경우의 모습을 보여주고 있다. 혼동해서는 안되는 것중 하나는 이러한 컴파일과정이 매번 사용자마다 발생하는 것은 아니라는 것이다. 우리 서버에는 taeyo.aspx 라는 파일이 존재하고 있고, 이 파일을 요청하는 사용자는 수십명에서 수천만명에 이르를 수 있다. 위의 코드 컴파일, Jit 컴파일은 매 사용자마다 발생하는 작업이 아니다. taeyo.aspx 라는 페이지를 처음 요청한 사용자의 의해 이는 코드 컴파일이 이루어지게 되고, 그 결과 관리코드가 어셈블리 캐쉬에 올라가게 된다. 그리고 나면, 다른 수백만명의 사용자가 taeyo.aspx 페이지를 요청할 경우, 어셈블리 캐쉬에 이미 존재하고 있는 관리 코드를 가져다가 사용하게 되는 것이다.

고로, 서버의 모든 aspx 페이지는 누군가가 처음 요청할 경우만 코드 파싱, 컴파일을 수행하고 그 후 어셈블리 캐쉬에 존재하게 하기에 처음 페이지를 요청한 사용자는 조금 느리게 결과물을 받을 수 있겠지만, 그 이후의 사용자들은 대단히 빠르게 어셈블리 캐쉬에 이미 존재하는 관리코드를 통해서 결과를 확인할 수 있다는 것이다.

다음 그림은 첫 요청에 의해 aspx 페이지가 어셈블리 캐쉬에 올라가 있어, 그 이후의 요청에는 빠르게 응답할 수 있는 바로 그러한 실행 흐름을 보여준다.

그림에서 볼 수 있다시피, 일단 첫 요청에 의해 어셈블리 캐쉬에 관리 코드가 존재하게 되면, 두번째 요청부터는 캐쉬로부터 빠르게 응답을 해 줄 수 있게 된다. 이것이 .NET의 장점인 것이다.

그렇다면, 만일 taeyo.aspx 페이지의 소스를 개발자가 수정하였다면 어떻게 될까? taeyo.aspx 라는 것의 컴파일된 관리 코드가 이미 어셈블리 캐쉬에 있는데, 원본 소스는 수정되었다. 이럴 경우 사용자는 수정된 소스에 의한 결과가 아닌 수정되기 이전의 결과를 볼 수 있다는 이야기인가?

그럴 경우, 현명한 ASP.NET은 수정사항을 감지하고, 어셈블리 캐쉬에 있던 해당 IL을 삭제하게 된다. 그리고, 수정된 taeyo.aspx 페이지의 첫 요청시 다시 처음부터 흐름을 시작하게 된다. 즉, 컴파일 단계를 다시금 거쳐서 어셈블리 캐쉬에 수정된 IL을 다시 올려놓는다는 이야기이다.

이 얼마나 현명한 ASP.NET 인가?

단, 만일 aspx 페이지가 코드 비하인드로 구성되어진다면, 그러한 경우, 클래스 파일이 수정될 경우는 개발자가 직접 그 클래스 파일을 컴파일해야 한다. 코드 비하인드에 대해서는 이후 자세하게 이야기할 것이니 지금은 그런 경우도 있다는 것만 알아두도록 하자.

결과적으로, 대부분의 aspx 페이지의 첫 요청은 개발자인 여러분들이 결과를 확인하면서 이루어질 것이다. 고로, 다른 일반 사용자들은 언제나 어셈블리 캐쉬에 있는 관리코드를 사용하게 될 것이고, 상당히 빠르게 결과를 받아볼 수 있게 될 것이다. 이것이 ASP.NET 이 빠르다는 근거인 것이다.

물론, 위의 실행 구조에서 빠진 부분이 하나 있다. 그것은 Output Cache 라는 것인데, 이는 위의 흐름보다 더욱 빠르게 사용자에게 응답을 해주기 위한 방법이다. Output Cache도 한 챕터를 차지할 만큼의 분량이기에 여기서 자세하게 이야기하기에는 무리가 따르지만, 간략히 설명하자면, 이는 사용자에게 최종으로 넘겨줄 두번째 컴파일 버전의 결과물을 캐쉬에 저장해 두는 방법이다. Output Cache 라는 특별한 캐쉬구역에 저장해 두게 되면, 사용자의 요청은 파싱, 코드 컴파일 단계, 런타임 컴파일 단계등을 거치지 않고, Output Cache 구역에 존재하고 있는 결과물로써 대단히 빠르게 응답해 줄 수 있게 된다. 그림으로 설명하자면 다음과 같은 흐름을 가지게 된다.


자. 이제 ASP.NET의 Execution Model 에 대한 이야기도 여러분이 충분히 이해한 것 같다. 물론, 여러분이 빨리 ASP.NET 코드를 작성하고 싶어하는 마음은 때오도 알고 있다. 하지만, 누누히 강조하였지만 이러한 기본적인 지식이 없이는 반쪽짜리 프로그램밖에 작성할 수 없다는 사실을 인지하기 바라는 마음이다.


ASP.NET Development Model

ASP.NET의 실행 구조를 알아보았으니, 이번에는 개발 흐름에 대해서 알아보도록 하자. 사실 대단한 것은 없다. 위의 실행 흐름을 이해했다면, 개발 흐름도 아주 쉽게 받아들여질 것이다.

이를 위해 먼저 이전 ASP.NET이었던 ASP 경우의 개발 흐름을 한번 보도록 하자. 만일, ASP 를 전혀 모르는 사용자라면 한번 그랬었구나 하는 마음으로 보아도 좋을 것이다.

ASP 때의 경우는 컴파일 언어가 아닌 인터프리트 언어를 사용했었기에, 컴파일이라는 단계가 필요하지 않았다. 단지 개발자의 몫은 단지 ASP 소스 코드를 수정하고 그냥 놔두기만 하면 되었다. 모든 ASP 페이지는 사용자의 요청시 서버에서 매번 인터프리트되었고, 그 결과를 클라이언트에게 건네어 주었다. 그로 인해, 매 페이지는 매번 파싱, 인터프리트 단계를 거치는 불합리함이 있었다. 하지만, 개발자의 입장에서는 단지 해당 소스만을 수정하면 그것으로 전부였기에 개발하기는 상당히 편리하였다.

ASP.NET으로 들어서면 이제는 컴파일 단계가 요구되어진다. 그것도 2번이나. 코드 컴파일 단계와 런타임 컴파일 단계를 거치고, 코드 컴파일이 되어진 관리 코드는 어셈블리 캐쉬에 올라가게 되어 이후 더욱 빠르게 서비스를 제공할 수 있게 된다. 해서 ASP.NET에서의 개발 흐름은 다음과 같은 모습을 띄게 된다.

이미 ASP.NET Execution Model을 이해하고 난 여러분은 개발상의 흐름을 이해하는 것이 전혀 어렵지 않다. 그렇지 않은가? 좋다. 이제 얼마남지 않았다. 여러분은 이제 곧 멋진 ASP.NET 의 코드들을 지겹도록 만나게 될 것이다.

출처 : (Taeyo.pe.kr)

2007/03/13 22:50 2007/03/13 22:50
Posted
Filed under .NET/ASP.NET

지난학기 웹프로그래밍(ASP.NET, C#이용) 시간에 만들었던 실습 자료들..!
VS 2005(닷넷 2.0기반)를 이용하여 만들었습니다...

MS SQL 버전은..2000을 이용하여 게시판,자료실등 제작..
XML을 이용하여 방명록 만들기..

문제는
1. 2.0들의 새로운 기능들이 나와있지 않는다는것!!-_-''(마스터 페이지와, 일부 데이터 그리드, 등등)
2. 일부 예제들이 잘못 동작 한다는것-_-''

2006/10/08 21:30 2006/10/08 21:30