ASP.NET
상태가 유지되는 객체 지향적인 윈폼 개발과 상태가 유지되지 않는 HTML 기반 웹 개발 간의 격차 해소를 추구하며, 서버 측 계층 구도로 사용자 인터페이스를 모델링함으로써 HTTP와 HTML을 모두 뒤편으로 감추고자 시도 하였으며, 각각의 컨트롤들은 요청들 사이에서 자신의 상태를 추적하며, HTML코드로 랜더링되며, 클라이언트 이벤트와 그에 대응하는 서버 측 이벤트 처리기 코드를 연결한다.
전통적인 이벤트 기반 GUI를 웹으로 끌어올리는데 초점을 맞춘 거대한 추상 계층이다.
ASP.NET의 문제점
ViewState : 요청 전반에 걸쳐 상태가 유지되는 이 기능의 메커니즘은 사실 클라이언트와 서버 사이를 빈번하게 오고 가는 거대한 데이터들로 인해서 얻어지는 결과로 모든 요청 시마다 매번 수신되고 다시 전송되므로, 응답 지연의 원인을 제공한다.
페이지 수명 주기 : 클라이언트 측 이벤트와 서버 측 이벤트 처리기 코드를 연결해 주는 메커니즘은 페이지 수명 주기의 한 부분이며, 경우에 따라서 이벤트 처리기의 실행이 실패하게 되거나 ViewState오류가 발생할 수 있다.
서버 컨트롤 : 서버 컨트롤이 자동으로 HTML로 랜더링되기는 하지만, 대체로 웹 표준을 만족하지 못하거나, CSS를 적용하기 어려운 구조일뿐만 아니라 서버 컨트롤이 생성한 ID값은 예측하기 어렵다
페이지단위 개발로 인하여 테스트에 어려움이 있다.
장점 : 컴파일 됨, 상태가 유지되는 UI 거대한 기반 구조, 객체 지향 프로그래밍 지향
단점 : 많은 대역폭 소모, 난잡한 HTML, 테스트의 어려움
ASP.NET MVC
MVC아키텍쳐의 사용
MVC응용 프로그램의 사용자 인터페이스는 자연스럽게 특정 반복 패턴을 따르게 되는데, 이와 같은 패턴은 일련의 HTTP요청과 응답을 제공하는 웹 응용 프로그램에 매우 적합하다.
확장성
있는 그대로의 기능을 사용하거나 기본 구현을 상속받아 하위 클래스를 구현하거나, 인터페이스 및 추상 클래스를 새롭게 구현하여 구성 요소 전체를 바꿀 수 있다.
테스트
응용 프로그램과의 관계를 분리하여 각각 별개의 독립적인 소프트웨어 조각으로 분리할 수 있어, 테스트 하기에 용이하다.
엄격한 HTML 제어
그 어떠한 ViewState 데이터도 포함하지 않으므로, ASP.NET 웹폼에서 페이지를 생성할 때보다 크기가 수백 킬로바이트 이상 작아질 수 있다.
강력한 새로운 라우팅 시스템
깔끔한 URL을 기본적으로 제공하여, 그 어떤 패턴에도 제약 받지 않고 URL을 정의할 수 있다. 그로 인하여 검색 엔진의 성능 향상, 웹 사용자들의 URL에 의한 페이지 직접 접근이 쉬워지며, 응용 프로그램의 기술적인 세부사항이나 폴더 및 파일 구조를 공개적인 인터넷에 노출시키지 않는다.
ASP.NET 과 MVC
ASP.NET이 더 이상 MS에서 지원하지 않는 기술이 아니다. 웹폼은 널리 사용되어지고 있는 기술이며, 상황에 따라 MVC보다 더 나은 경우도 분명히 존재한다. 작은 규모의 인트라넷 유형의 응용프로그램의 경우에는 MVC보다 웹폼이 더 낫다고 볼 수 있다. 그렇기 때문에 두 플랫폼 중 무엇을 선택해야 하는지는 상황에따라 적절하게 선택해야 할 문제이다.
