검색결과 리스트
글
- ViewState
- 요청 전반에 걸쳐 상태가 유지되는 이 기능의 매커니즘은 사실 클라이언트와 서버 사이를 빈번하게 오고가는 거대한 데이터들로 인해서 얻어지는 결과다. 많은 실무 응용 프로그램에서 이 데이터들은 수백 킬로바이트에 이르는 경우도 빈번하며, 모든 요청 시마다 매번 수신되고 다시 전송되므로, 사이트 방문자가 버튼을 클릭하거나 그리드에서 다음 페이지로 이동하려고 할 때 응답 지연의 원인을 제공하여 방문자를 지치게 만든다. 큰 대역폭을 차지하는 페이지의 개인 문제야 말로 Ajax가 해결책을 제시해 줄 수 있는 대표적인 문제들 중 하나임에도 불구하고 ASP.NET Ajax 역시 이 문제가 존재한다.
- ASP.NET Ajax도 매번 비동기 요청을 수행할 때마다 페이지의 모든 ViewState를 수신하고 전송한다.
- 페이지 생명 주기
- 클라이언트 측 이벤트와 서버 측 이벤트 처리기 코드를 연결해 주는 매커니즘은 페이지 수명 주기의 한 부분이며, 경우에 따라서 상당히 복잡 미묘해질 수도 있다. 단지 소수의 개발자들만이 이벤트 처리기의 실행이 모호하게 실패하는 일이나 ViewState 오류 없지 런타임 시에 컨트롤 계층 구조를 조작할 수 있다.
- 제약이 많은 HTML 기반의 컨트롤
- 서버 컨트롤은 자신을 HTML로 렌더링하기는 하지만, 그 결과가 내가 생각한 결과와 같다고 장담 할 수는 없다. 서버 컨트롤의 HTML은 대체로 웹 표준을 만족하지 못하거나 CSS를 적용하기 어려운 구조일 뿐만 아니라 서버 컨트롤 시스템이 생성한 ID값은 예츠갛기 어렵고 복잡하여 자바스크립트로 접근하기 힘들다.
- 서버 컨트롤에서 GridView나 기타의 데이터를 자동으로 Bind해 주는 서버 컨트롤의 경우, 컨트롤 자체적으로 렌더링 시에 Table 코드르 만든다. 이렇게 만들어진 Table 코드는 웹표준 방식에 맞지가 않는다. 그리고 각 렌더링된 컨트롤의 ID값은 각 컨트롤의 ClientID값으로 확인이 가능하나, 자신의 페이지가 아닌 다른 페이지에서는 접근이 제한이 된다.
- 취약한 관계의 분리
- ASP.NET의 코드-ㅣ하인드 모델은응용 프로그램 코드를 HTML 마크업과 분리하여 별도의 코드-비하인드 클래스에 작성할 수 있는 방법을 제공한다. 이 모델은 로직과 프리젠테이션을 분리하는 방법으로 널리 박수를 받았으나, 실제로 개발자들은 프리젠테이션 코드와 응용프로그램 로직을 하나의 거대한 코드-비하인드 클래스에 뒤 섞어 구현할 수밖에 없었다. 그래서 뛰어난 관계의 분리를 도입하지 않고 얻어진 결과물들은 대체로 취약하고 난해했다.
- 테스트의 어려움
- ASP.NET의 설계잘들은 그 첫 번재 플랫폼을 설계하면서 오늘날과 같이 자동화된 테스트가 소프트웨어 개발의 주류로 성장할 것이라는 예견을 하지 못했다. 따라서 그들이 설계한 아키텍처가 자동화돈 테스트에 적합하지 않은 것은 당연한 일이다.
설정
트랙백
http://www.mayaul.com/trackback/52
댓글
RECENT COMMENT