포스트 백과 콜백의 차이점
답변:
Postback은 페이지의 데이터 (전체 페이지)가 클라이언트 에서 서버로 게시 될 때 발생합니다. 즉, 데이터가 서버로 다시 게시 되어 페이지가 새로 고쳐집니다 (다시 그려집니다). ' 서버에 데이터로 가득 찬 전체 페이지 (asp.net)를 전송합니다 .
반면에 콜백은 또한 특별한 종류의 포스트 백 이지만 작은 데이터 집합 (일반적으로)을 얻기 위해 서버로의 빠른 왕복 일 뿐이므로 포스트 백과 달리 페이지가 새로 고쳐지지 않습니다. ... ' 서버를 호출하고 일부 데이터를 다시 수신 ' 하는 것으로 생각하십시오 .
Asp.Net을 사용하면 포스트 백과 달리 콜백이 호출 될 때 ViewState가 새로 고쳐지지 않습니다 .
ASP.Net은에서 전체 페이지를 둘러싸고 있기 때문에 전체 페이지가 ASP.Net에 게시되는 이유는 <form>와 포스트 방법 및 버튼 페이지에서 클릭 제출 때, 양식 모두와 함께 서버로 전송됩니다 양식에있는 필드 ... 기본적으로 전체 페이지 자체입니다.
FireBug (Firefox 용)를 사용 하는 경우 실제로 .NET Framework 에서 서버에 호출되는 콜백을 볼 수 있습니다 Console. 이렇게 하면 서버로 전송되는 특정 데이터 ( Request)와 서버에서 다시 보낸 데이터 ( Response)를 볼 수 있습니다.
아래 이미지는 ASP.NET 기반 웹 사이트에서 포스트 백과 콜백의 페이지 수명주기를 보여줍니다.
(출처 : esri.com )
Dreas의 답변에 동의하지만 몇 가지 포인트를 추가하고 싶습니다. Postback은 Dreas가 설명했듯이 ASP .NET 프로그래밍에서 최근에 도입 된 용어이지만 콜백은 더 일반적이며 웹 개발이 존재하기 전에 사용되었습니다. 사실 저는 C로 프로그래밍을 시작했을 때 콜백에 대해 처음 들었습니다 (아마도 그 용어가 이전에 존재했을 수도 있습니다). 이것은 단순히 함수에 대한 포인터와 함수에 대한이 포인터 (이름이 A)를 의미합니다. 나중에 A를 호출 할 다른 함수 (이름이 B)로 전달됩니다. 콜백은 최근 Yahoo UI 연결 관리자 및 기타 Ajax 프레임 워크에서도 사용되지만 이전 C 시절에 처음 사용 된 용어라고 생각합니다.
이 토론의 대부분은 ASP.NET gobbledygook 언어입니다 ....
대답은 '예'입니다. 포스트 백은 Microsoft의 ASP.NET에 고유 한 "용어"입니다. 그러나 Microsoft와 같은 공급 업체는 이러한 프로세스의 자체 버전을 자체 구현에 래핑하여 Http / Html 세계에서 실제로 일어나는 일에 대해 우리 모두를 혼란스럽게합니다.
POSTBACK의 버전은 기본적으로 원래 서버로 다시 전송되는 전통적인 HTTP POST 요청입니다. 그러나 ASP.NET에서는 웹 페이지의 작은 부분에 전통적인 양식 컨트롤이 아닌 전체 웹 페이지에 거대한 FORM HTML 요소 태그 (POST 메서드 속성 포함)를 부착하여 수행합니다. 그들은 HTTP 사양을 사용하여 페이지 및 해당 컨트롤의 "상태"를 유지하고 기존의 비 형식 필드 마크 업을 포함하여 전체 페이지가 손상되지 않았는지 확인하기 때문에 이렇게합니다.
불행히도, 이것은 엄청난 양의 불필요한 데이터를 유선을 통해 전송하여 페이지의 VIEWSTATE와 자매 POSTBACK이 대역폭 낭비와 웹 페이지 상태를 구현하는 조잡한 방법으로 많은 사람들에게 보여지게되었습니다. 캐시 가능한 CSS와 일관된 HTML 마크 업을 사용하여 설계된 대부분의 최신 브라우저와 웹 사이트는 브라우저의 기본 HTML 캐시를 사용하여 페이지 상태를 매우 자연스럽게 반환 할 것입니다. 즉 전체 POSTBACK은 종종 불필요합니다.
CALLBACK은 JavaScript 일뿐입니다. 그것의 단지 ECMASCRIPT 서커스는 브라우저가 서버에서 다운로드하는 거대한 JavaScript 라이브러리에서 AJAX API라고 부르는 것에 ASP.NET이 저장하고, ASP.NET 개발자는 전체 POSTBACK없이 웹 페이지에서 변경 사항을 트리거하기 위해 자신도 모르게 웹 페이지에 압축합니다. AJAX 용 ASP.NET API는 클라이언트 측에 있고 사용자가 무언가를 변경하거나, 무언가를 롤오버하거나, 브라우저에서 무언가를 클릭 할 때 브라우저에서 트리거되는이 모든 거대한 자바 스크립트를 생성하여 전통적인 자바 스크립트 브라우저 DOM 이벤트를 트리거합니다. 그런 다음 처리 할 엄청난 양의 JSON 또는 기타 데이터를 서버로 다시 보냅니다. 그런 다음 브라우저의 메모리에있는 Javascipted 라이브러리 및 개체에 의해 반환되고 수락되며 사용자 웹 페이지 및 마크 업의 일부가 변경됩니다.
사용자와 브라우저의 약 5 ~ 10 %가 자바 스크립트를 사용하지 않도록 설정했기 때문에이 모든 JSON 및 AJAX가 이러한 사람들을 위해 충돌하고 화상을 입을 것이라고 말했습니다. 즉, CALLBACK이 작동하지 않습니다.
그것이 뒤에서 일어나는 일입니다. 당신이 나에게 묻는다면 그것의 대부분은 과잉입니다. 이것이 ASP.NET의 웹 컨트롤 모델이 과거에 비판을받은 이유입니다.
ASP.NET을 잠시 중단 한 경우 단일 텍스트 상자와 단추가있는 HTML 웹 페이지에 간단한 FORM 필드를 직접 작성하고 눌러서 서버에 게시하는 것을 볼 수 있습니다. 마치 ASP.NET 페이지처럼 더 빠르고 간단합니다. 이것이 진정한 POSTBACK입니다. 브라우저는 자연스럽게 서버에 필요한 POST HTTP 헤더를 보내지 만 페이지의 나머지 부분에 HTML을 캐시하므로 자체적으로 매우 빠르게 렌더링됩니다.
CALLBACK의 경우 사용자가 일부 텍스트 또는 버튼 위로 마우스를 이동하거나 양식 필드를 클릭하거나 변경할 때 웹 페이지가 POST를 수행하지 않지만 백그라운드에서 사용자가 수행하는 동일한 HTML 페이지에 간단한 Javascript / ECMAScript 코드를 추가 할 수 있습니다. Javascript가 서버에 무언가를 보내도록하십시오. 자체 JavaScript, JSON 또는 라이브러리를 통해이를 처리하는 방법은 또 다른 문제입니다. 그러나 그것은 마술이 아닙니다. Javascipt 또는 Javascript를 사용하지 않는 사용자의 경우 CALLBACK없이 페이지를 디자인하고 양식 필드 컨트롤 또는 하이퍼 링크를 클릭 할 때 반환되는 변경 사항을 캐시해야합니다. 대부분의 최신 사용자 에이전트는 이제 ECMAScripted 웹 사이트 루틴에 맞게 설정되어 있지만 콜백 루틴을 재고해야하는 이유 중 하나입니다.
이것이 사람들을 혼란스럽게하는 것입니다. 매우 기본적인 HTTP 요청과 자바 스크립트 트릭의 이러한 벤더 구현은 명확하지 않은 언어로 계층화됩니다. 그런 다음 사람들은 매우 간단한 코딩으로 해결할 수있는 불필요한 모든 작업을 수행하는 괴물 같은 웹 애플리케이션을 구축하게됩니다.
나는 여전히 ASP.NET을 사용하고 권장합니다. 먼 길과 훌륭한 시스템이 왔습니다. 그러나 더 많은 사람들이 사용하기 전에 수행하는 작업의 기본 사항을 이해하면 도움이 될 것입니다. 이러한 프레임 워크는 내부에서 실제로 진행되는 작업을 볼 때 개선하기 위해 상당히 사용자 정의하고 단순화 할 수 있기 때문입니다.
포스트 백은 요청이 서버로 전송 될 때 발생하며 각 요청의 보안에 대한 세부 정보를 제공 할 필요가 없습니다.
다른 페이지 콜백을 요청하면 서버에서 사용됩니다.