ASP.NET 3.5

Tim Berners-Lee에 의해서 HTTP를 통한 전송이 성공하고 나서 웹은 급격하게 성장을 이루었습니다. 시스템에 상관없이 데이터를 전송하고 표현하기 위한 시도들이 이루어졌고, 그 결과 HTML과 XML이 태어나게 됩니다. 이 후로도 급격한 성장을 이루어 웹을 통해 모든 데이터가 소통되고 수많은 웹어플리케이션이 개발되면서 기업들은 환경에 구애 받지 않는 통합된 웹 개발 환경을 가지고 쉽게 설계하고, 개발하고, 서비스할 수 있는 것을 원하기 시작했습니다.

이런 결과로서 많은 소프트웨어 벤더들인 이러한 시도에 참여하게 되었고, ASP.NET도 그 결과물 중에 하나입니다. .NET로 통합된 환경은 3.5버전까지 출시되기에 이르렀고 통합된 막강한 개발환경으로 효율적이고 생산적인 개발을 지원하는 대표적인 IDE/언어/Framework로 자리매김하고있습니다.

초창기 웹

처음 HTML만으로 이루어진 정적인 페이지를 서비스하다가 동적인 서비스를 할 수 있는 기술이 소개되었습니다.

• 서버에서 실행되는 프로그램, CGI : 서버에서 실행되어 사용자의 요구에 맞추어 동적인 페이지를 반환할 수 있도록 하는 프로그램입니다. 혁신적인 기술 이었지만 한번의 요청마다 하나의 프로세스를 생성하는 비효율적인 자원 소비로 인해 현재는 거의 사용되지 않는 기술입니다.
• 서버에서 실행되는 Script, PHP, ASP, JSP : 스크립트와 컴파일언어의 차이점을 말한다면, 아마도 해석되는 시점과 소스코드의 위치의 차이가 될것입니다. 컴파일 되지 않는 상태로 HTML과 함께 한페이지에 존재하다가, 페이지가 요청되면 한줄한줄 씩 해석되어 실행됩니다. 이러한 언어는 급격하게 퍼지고 많은 사랑을 받고, 현재까지도 애용되고 있는 방식이긴 하지만 코드의 혼잡성, 하드코딩으로 인한 개발 효율 저하, 비효율적인 개발/디버깅 환경, 통합되지 않는 개발환경을 가진다는 단점을 안고있습니다. 물론 일부분은 해결되고 있지만 여전히 개발에 있어 효율성은 떨어집니다. CGI보다 훨씬 효율적으로 자원을 소모하지만, 현재 ASP.NET나 JSP와 같은 컴파일되어 서비스 되는 언어보다 속도에서 많이 떨어진다는 단점이 있습니다.
• 그리고 ASP.NET : 통합된 개발환경, 효과적인 디버깅 환경, 월등한 생산성, 컴파일 언어의 속도까지, 현재까지 웹 어플리케이션 개발에서 안고 있었단 대부분의 단점을 해결된 통합 개발 환경이 ASP.NET입니다. 기존의 발전된 Windows Applition개발환경과 언어의 장점까지 모두 흡수하여 개발자와 기업에게 개발에 있어 많은 이익을 가져다 주는 언어로서 현재 시점에서 많은 기업들에 의해 채용되고 또한 급격하게 확산되어가는 추세이 있습니다.

ASP가 공개되었을때, 수많은 개발자에게 있어서는 완벽한 언어였습니다. 기존에 자신이 알고있던 개발 언어의 문법으로 추가적인 웹에 대한 이해만 있다면 웹 개발을 할 수 있었기 때문입니다. 그리고 각종 확장 기능을 ASP에서 사용할 수 있었기 때문에, 확장성 까지 갖춘 최고의 언어였습니다.

하지만 곧 많은 단점들이 드러나기 시작합니다. 일단 모든 변수가 variant타입으로서 많은 메모리의 차지는 물론 속도의 저하까지 가져왔으며, 변수의 타입은 실제로 동작하기 이전까지 개발자가 추측은 할 수 있었지만 정확하게 알 수 없었습니다. 물론 수많은 ASP개발 환경이 Text-Editor일 수 밖에 없었던 이유는 역시 뛰어난 확장성과 알수 없는 변수 타입으로 실제 해석되기 전까지 정확한 변수 사용인지, 정확한 컴포넌트 사용인지 개발 툴에서 검사하기 힘들다는 점입니다.

이러한 단점을 개선하고자 ASP.NET는 ASP로부터 많은 것을 버리고 새로운 것을 받아 들였습니다. 비록, ASP.NET는 개발자에게 새로운 환경, 문법, 기술 등을 익히도록 강요하였지만, 그를 만회하고도 남는 엄청난 개발 효율성으로 많은 사랑을 받고 있습니다. 기존의 스크립트 방식에서 컴파일 방식으로 변화되어 속도에서또한 월등합니다.

.NET Framework를 기반으로하는 ASP.NET

.NET Framework는 수많은 클래스 라이브러리를 지원합니다. 체계적으로 namespace에 의해 체계하된 클래스 라이브러리를 언제든지 사용할 수 있습니다.

Interprete가 아닌 Compile되는 ASP.NET

Interprete 언어가 Compile언어보다 느리다는 점은 이미 널리 알려진 사실입니다. 모든 .NET 언어와 마찬가지로 ASP.NET도 컴파일되어 작동합니다. 모든 .NET언어는 먼저 언어중립적 코드인 중간언어로 바뀝니다.(IL : Intermediate Language) 이 IL은 어셈블리 파일로서 페이지가 호출되고 실행되기 직전에 JIT(Just-in-Time) Compiler에 의해 저레벨 기계어 코드로 바뀝니다. 어셈블리 파일인 IL은 .NET Framework가 실행되는 모든 환경으로 배포되어 사용될 수 있습니다.

하지만 매번 사용자의 실행 요청마다 IL로 변환하고, 또다시 기계어 코드로 변환하는 것은 좋지 않은 현상입니다. 다행스럽게도, 첫번째 수행 요청이 있을 때, IL로 해석되고, 기계어 코드 역시 Framework의 Temporary폴더에 저장되고, 또한 캐시되어 실행 속도를 향상시킵니다.

어셈블리 파일의 Disassemble

IL 코드를 확인하기 위해서는 IL Disassembler를 실행하여 DLL이나 EXE파일을 선택하시면 됩니다. 시작->VisualStudio 폴더-> Visual Studio 200X Command Prompt를 실행하여, ildasm.exe를 실행하시면 Disassembler가 실행됩니다. Visual Basic와 C#으로 동일한 기능을 하는 간단한 프로그램을 역어셈블하면 어셈블리 코드가 거의 같다는 것을 알 수 있습니다. .NET에서 다른 언어로 같은 기능을 하는 프로그램을 만들면, 약간의 차이가 있을 확률은 있겠지만, CLR이 따르는 CLS에 의해 거의 같은 성능을 낼 수 밖에 없습니다.

CLS(Common Language Specification)

CLR(공용 언어 런타임)은 모든 객체들과 상호작용하기 위해 특정한 룰을 제공합니다. 이 룰의 집합이 CLS입니다. CLS는 모든 언어들이 반드시 따라야하는 규칙을 말합니다. CLR환경에서 작동하는 IL코드를 생성하는 컴파일들은 CLS에 따른 룰을 따릅니다.

Common Language Runtime과 ASP.NET

ASP.NET는 .NET Framework라는 CLR환경에서 동작합니다. .NET Framework환경에서 동작함으로서 얻을 수 있는 이익은 다음과 같습니다.

• Garbage Collection : .NET Framework는 .NET 프로그램들의 메모리 할당과 해제를 관리합니다. 예전의 C/C++과 같이 메모리 할당과 해제에 관해서 힘들어 하실 필요없습니다. 참조가 되지 않는 모든 영역은 해제되며, 모든 메모리 공간 요청은 자동적으로 .NET Framework에서 할당되고 관리됩니다.
• Type Safety : 프로그램이 컴파일될 때, 어셈블리 파일에 사용가능한 클래스, 멤버, 데이터 타입등의 정보를 담습니다. 따라서 다른 어플리케이션이 해당 어셈블리를 호출한다고 하더라도, 적절한 정보를 제공해줄 수 있고 유효성 검사까지 할 수 있습니다.
• Extensible metadata : 클래스나 메서드에 부여할 수 있는 메타 데이터는 .NET에 의해 어셈블리에 포함이 됩니다. 이러한 메타데이터를 통해 코드를 어떻게 추적하고, 어떻게 컨트롤을 출력할지, 트렌젝션 처리와 풀링은 어떻게 할지 등을 시스템에 알려 줄 수 있습니다.