1 B/S가 좋은 사용자 상호작용 경험을 제공하는 것이 왜 어려운가요?
여기서 가장 큰 문제는 다음과 같습니다.
(1) Stateless HTTP 프로토콜
Windows Forms는 메모리를 통해 직접 정보를 교환할 수 있지만, B/S 아키텍처 통신의 기본 프로토콜인 HTTP는 Stateless입니다.
브라우저가 게스트로 간주되고 웹 서버가 호텔로 간주되는 경우 HTTP 프로토콜 관리 하에서 이러한 상황이 발생합니다. 게스트가 몇 번 방문하더라도 웹 서버는 그를 첫 번째로 간주합니다. 시간 방문자. 이런 방식으로 고객은 호텔 직원이 "신원 확인"을 할 수 있도록 매번 신분증을 지참해야 합니다.
HTTP 프로토콜의 무상태성은 웹 서버의 "무시"로 이어집니다. 이는 웹 서버의 처리량을 증가시킬 수 있지만 응용 프로그램 시스템 개발에 문제를 가져옵니다. 본질적으로 정보가 흐르는 애플리케이션 시스템에는 많은 비즈니스 처리 프로세스가 있기 때문에, 즉 원본 데이터가 한쪽 끝에서 들어오고 다른 쪽 끝에서 나올 때 특정 처리를 거쳐야 한다는 것을 어떻게 상상할 수 있습니까? 전체 비즈니스 프로세스의 정보가 손실됩니까? 따라서 HTTP 요청 간에 정보를 공유하는 것은 골치 아픈 문제가 됩니다. 이것이 바로 HTTP 요청의 "상태 유지" 문제입니다. 모든 B/S 시스템은 이 문제를 해결해야 합니다. Microsoft는 HTML 웹 페이지의 숨겨진 필드를 최대한 활용하고 웹 서버에서 몇 가지 트릭을 수행하는 등 몇 가지 "비뚤어진 트릭"을 생각했습니다. 따라서 ASP.NET에는 각 HTTP 요청 간에 상태를 유지하는 일련의 기술이 있습니다. 세션, 쿠키, ViewState, 프로필, 애플리케이션.
그러나 문제가 완전히 해결되지는 않습니다. 예를 들어, 사용자 입력 정보를 수집하는 C/S 시스템의 일반적인 대화 상자에서는 기본 폼과 대화 상자(모달과 넌모달의 두 가지 유형으로 구분됨) 사이에 정보 교환이 있습니다. 전자 대화 상자 상자는 닫히지 않습니다. 기본 양식은 활성화될 수 없습니다.) B/S 아키텍처에서는 브라우저의 각 요청이 독립적이므로 두 개의 독립적인 브라우저 창 간에 모달 대화 상자와 유사한 직접적인 정보 교환이 구현되어야 합니다. 무엇을 해야할지 모르겠습니다.
AJAX는 다음 방법을 사용하여 모달 양식을 "시뮬레이트"합니다. 기본 양식과 대화 상자를 하나로 "결합"합니다. 대화 상자는 일반적으로 필요할 때 숨겨지고 표시되는 HTML의 div 요소입니다. Microsoft의 AJAX Control Toolkit에는 이 기능을 위해 설계된 컨트롤도 있습니다. B/S 개발에는 이런 트릭이 셀 수 없이 많습니다.
C/S에서 쉽게 구현할 수 있는 많은 기능이 B/S에서는 구현하기가 매우 어렵다는 것을 알 수 있다.
(2) 특수 동작 환경 - 브라우저
B/S 시스템의 프런트 엔드 운영 환경은 브라우저이므로 하드웨어(예: 프린터)에 직접 액세스하는 등 많은 작업을 수행할 수 없으며 하드웨어 리소스를 최대한 활용할 수 없습니다. 예를 들어, 오늘날의 새로운 컴퓨터는 모두 듀얼 코어입니다. JavaScript와 HTML을 직접 사용하여 이 두 개의 "펜티엄 코어"를 최대한 활용하는 멀티 스레드 프로그램을 작성할 수 있습니까?
C/S 시스템은 OS(운영체제)에서 직접 실행되며 OS에서 제공하는 모든 기능을 호출할 수 있습니다.
(3) 당황스러운 웹 클라이언트 프로그래밍 언어 -
전통적인 C/S 프로그램인 JavaScript는 다양한 개발 언어, 특히 C++, Java, C#과 같은 주류 객체지향 언어를 많이 사용할 수 있습니다. 강력하고 사용하기 쉽습니다. 다양한 개발 도구를 사용할 수 있으며 매우 성숙합니다.
반면, B/S 프론트엔드에서 가장 많이 사용되는 프로그래밍 언어인 JavaScript는 "JavaScript를 사용한 프로그래밍"을 자질구레한 일로 여기는 많은 프로그래머들에게 싫어할 뿐만 아니라 심지어 "미움"을 받기도 합니다.
JavaScript의 두 가지 주요 단점을 살펴보겠습니다.
첫째, 명확하고 통일된 프로그래밍 모델이 부족합니다.
JavaScript는 이름에 Java가 있고 유사한 구문을 사용하지만 실제 Java와는 아무런 관련이 없습니다. 안타깝게도 그녀는 미운 오리 새끼입니다. 그녀는 항상 백조가 되고 싶어하지만 다른 사람들이 자신의 아이디어를 받아들이지 않을 것이라고는 생각하지 않습니다.
JavaScript는 많은 객체를 사용하지만, 객체지향이라고 하기에는 정말 설득력이 없습니다(객체지향 프로그래밍의 기본 단위는 클래스입니다). 예를 들어 주류 객체지향 언어와 유사한 키워드 클래스가 없습니다. C#과 같은 모든 코드는 클래스 형식으로 명확하게 정의하기 어렵고 구조화되어 있지 않습니다(구조적 프로그래밍의 기본 단위는 함수입니다). 브라우저는 HTML 문서를 구문 분석할 때 스트림을 사용하기 때문에 HTML 문서를 구문 분석할 때 일부 JavaScript 코드가 함수 외부에 배치되어 직접 실행되는 반면, 함수에 배치된 코드의 다른 부분은 대부분 이벤트 중심으로 실행됩니다. 이는 복잡한 문제를 야기합니다. 프로그램 실행 흐름은 순수하게 구조화된 프로그래밍에서 함수 호출을 통합적으로 사용하는 것보다 훨씬 덜 간결합니다.
이러한 관점에서 보면 JavaScript는 객체지향, 구조화, 비구조화 프로그래밍 방식의 특징을 갖고 있지만 명확하고 통일된 프로그래밍 모델을 갖고 있지 않습니다. 구조와 손쉬운 유지관리에 많은 혼란이 왔습니다.
둘째, JavaScript의 또 다른 결함은 브라우저 실행 환경입니다.
역사적 이유로 인해 브라우저마다, 심지어 동일한 브라우저의 버전마다 프로그래밍 모델이 다소 다르기 때문에 브라우저 유형을 감지하는 코드를 작성해야 합니다. IE와 FireFox를 위한 또 다른 세트를 작성했습니다. 이것은 정말 번거로운 일입니다.
위의 문제는 B/S 아키텍처 시스템의 "고유적인" "결함"에 가깝습니다. 선천적 결함은 양육으로 보완되며, 사람들은 이러한 문제를 해결하기 위해 많은 트릭을 생각해 냈습니다. AJAX는 모두가 낙관하는 희망의 별입니다.
2 Star of Hope - AJAX
지난 며칠 동안 저는 Microsoft의 AJAX 프레임워크에 대해 체계적으로 배웠습니다. AJAX 프레임워크를 설계한 Microsoft 엔지니어들은 이 프레임워크의 복잡성이 제가 예상한 것보다 훨씬 더 복잡하다는 사실을 발견했습니다. AJAX 프레임워크를 설계한 Microsoft 엔지니어들은 다양한 웹 개발 기술의 잠재력을 깊이 탐구하여 이전에 제기된 문제를 상당 부분 보완했습니다.
(1) JavaScript 언어의 확장:
Microsoft는 상속, 인터페이스 정의, 개체 직렬화, 이벤트 트리거 및 반사 유형과 같은 기능을 쉽게 구현할 수 있는 캡슐화된 AJAX 라이브러리를 제공하여 JavaScript의 개체 지향 기능을 향상시켰습니다. 객체 지향 언어(예: Java/C#) 사이에는 여전히 격차가 있지만 "추악한" JavaScript를 눈에 보이는 것으로 꾸미는 것은 놀라운 일로 간주됩니다.
AJAX 라이브러리 지원과 향상된 JavaScript 기능, 그리고 브라우저 자체의 지원을 통해
브라우저 측 코드의 기능을 대폭 향상하여
브라우저에서 JavaScript 스크립트를 작성하여 쉽게 비동기 요청을 할 수 있습니다.부분 페이지 새로 고침을 실현하고 웹 서비스를 직접 호출할 수 있습니다.
(3) 컴포넌트 기반 개발(CBD) 방법 소개
컴포넌트 기반 개발(CBD)은 오랫동안 객체지향 시스템의 주류 개발 방법이었습니다. 현재 SOA(서비스 기반 아키텍처)는 매우 과장되어 있지만 여전히 필요합니다. CBD만큼 성숙하려면 어느 정도 시간이 걸립니다.
SOA는 물론 JavaScript의 경우 CBD 구현이 매우 어렵습니다.
CBD를 실현하기 위해 Microsoft는 JavaScript를 "대대적으로 개선"하고 Microsoft AJAX 라이브러리를 기반으로 많은 기능을 강화했습니다. 프로그래머는 다음과 같은 세 가지 유형의 재사용 가능한 구성 요소를 개발할 수 있습니다. None_Visual 구성 요소(보이지 않는 구성 요소, 객체 지향 시스템과 동일) 그 중 공용 기능 제공), 동작(동작, 기존 웹 컨트롤의 기능 확장) 및 컨트롤(시각적 인터페이스 요소가 있는 웹 컨트롤)이 있습니다.
특히, AJAX Control ToolKit에서 제공하는 수십 개의 컨트롤은 기본적으로 C/S 사용자 인터페이스의 대부분 기능에 대한 B/S 시뮬레이션을 구현하며, 이 새로운 프로그래밍 모델을 적용하기 위한 모델입니다.
Microsoft의 향상된 JavaScript 프로그래밍 모델을 통해 소프트웨어 엔지니어는 CBD 개발 방법을 사용하여 최종적으로 웹 클라이언트 코드를 개발할 수 있습니다. 나는 이것이 진전이라고 생각한다.
(4) 향상된 서버 측 기능
브라우저 측 코드의 기능을 향상시키기 위해서는 서버 측을 통해 조정되어야 합니다. AJAX 자체는 브라우저와 웹 서버가 서로를 지원하는 프로그래밍 모델을 기반으로 합니다(웹 서버는 데이터 서비스를 제공하고 브라우저는 웹 서버에 비동기 요청을 하기 위해 XMLHttpRequest 객체를 제공합니다. 데이터가 돌아오면 프로그래머는 JavaScript로 코드를 작성하여 웹페이지의 동적 부분 처리를 구현합니다.
AJAX 확장을 통해 Microsoft는 서버측 ASP.NET 프레임워크의 기능을 향상시켰습니다. 그리고 일반적으로 사용되는 기능을 AJAX의 핵심 컨트롤인 ScriptManager, 페이지의 업데이트 가능한 영역을 정의하기 위한 UpdatePanel, 기존 ASP.NET 컨트롤(즉, Extender 컨트롤에 연결된 컨트롤)을 향상시키기 위한 수십 개의 AJAX Control Toolkit과 같은 간단한 웹 컨트롤로 외부화합니다. 기존 컨트롤에 새로운 기능을 확장하는 것이 목적인 기존 컨트롤)
이러한 컨트롤을 사용하면 웹 프런트 엔드 프로그램을 개발하는 것이 VB에서 양식을 디자인하는 것과 유사합니다. 이제 Windows Forms와 유사한 인터페이스를 그리는 것이 가능할 뿐만 아니라 AJAX의 비동기 요청 및 페이지 부분 새로 고침 기술을 사용하고 웹 서버의 협력을 통해 사용자 경험을 Windows Forms에 강제 적용할 수 있습니다.
아무리 많은 사람들이 VB를 무시하더라도 VB가 가져온 시각적 프로그래밍의 대중화 물결은 실제로 광범위한 영향을 미쳤습니다. JavaScript 프로그래밍 이 단계에 대한 Microsoft의 추진도 일반적인 추세입니다. 웹 개발의 효율성을 높이려면 이 단계를 수행해야 합니다.
하지만 아무리 '보충'해도 결국은 '선천적 결함'이고 사용자 경험 측면에서 B/S 아키텍처가 C/S를 능가하는 것은 여전히 매우 어렵다는 점을 지적할 필요가 있다. .
3 미래: B/S 또는 C/S,
관리 및 배포의 단순성으로 인해 B/S 아키텍처는 오늘날 많은 정보 시스템에서 첫 번째 선택이 되었습니다. 그러나 사용자는 좋은 사용자 경험을 추구합니다. . 요약하면 다음과 같은 요구 사항이 필요합니다.
(1) 아름다운 인터페이스. 이런 점에서는 B/S가 유리합니다.
(2) 입력이 편리합니다. 예를 들어 많은 사용자는 마우스를 사용하지 않고 데이터를 입력하거나 간단한 클릭만으로 데이터를 자동으로 채우는 것을 B/S 아키텍처에서는 구현하기 어렵습니다.
(3) 번개 속도. C/S의 경우 빠른 응답속도를 달성하는 방법은 여러 가지가 있지만 B/S의 경우 쉽지 않습니다. 브라우저 제한으로 인해 클라이언트의 강력한 하드웨어 리소스가 거의 유휴 상태입니다. 또한 네트워크 속도는 B/S 아키텍처의 병목 현상입니다. 대역폭이 급격히 증가하지 않는 한 WWW는 World Wide Wait가 될 것입니다.
C/S는 좋은 사용자 경험을 제공하지만, 인터넷 전체를 포괄하는 분산 시스템을 개발하기 어렵다는 점, 게다가 클라이언트를 설치해야 하기 때문에 시스템 업데이트와 구성 요소 버전 관리가 큰 문제가 됩니다. 또한 B /S 아키텍처와 달리 서버측 문제만 고려하면 됩니다. C/S 아키텍처에서는 동시에 여러 사용자가 서버에 액세스하므로 구성 요소 간의 호출 및 종속성이 복잡합니다. 공유 리소스에 대한 다중 스레드 액세스, 트랜잭션 처리 등을 처리할 때도 고려해야 합니다. 서버 측에서는 처리량이 크게 제한됩니다. 따라서 C/S는 대부분 기업 내부에서 사용하기 위해 근거리 통신망에 구축됩니다.
현재 B/S와 C/S는 기본적으로 공존하고 있으며, AJAX 등 B/S 기술이 널리 적용되면서 B/S가 지속적으로 우위를 점하고 있지만 C/S를 완전히 압도하는 것은 불가능합니다. .
더 흥미로운 점은 마이크로소프트 같은 대기업들은 B/S와 C/S의 개발 전망을 어떻게 보는가이다.
나와 같은 일반 개발자는 Microsoft 경영진과 직접 대화할 기회가 없지만 회사의 제품 개발 경로에서 몇 가지 단서를 볼 수 있습니다.
마이크로소프트는 B/S가 기술 발전의 미래 방향을 대표한다고 생각하지 않는 것 같다. 오히려 많은 행동이 브라우저를 포기하는 방향으로 움직이고 있다.
우선 마이크로소프트는 C/S 개발과 배포를 단순화하고 스마트 클라이언트 기술을 출시해 C/S 클라이언트 프로그램의 업데이트가 수동 개입 없이 자동으로 이루어질 수 있도록 했다.
둘째, 마이크로소프트는 B/S와 C/S 간의 격차를 해소하기 위해 노력했다. ASP.NET을 설계할 때 좋은 결과를 얻었던 ASP를 과감히 버리고, 이와 유사한 '시각적 제어 + 이벤트 중심' 프로그래밍 방식을 직접 채택했다. VB에서는 웹 페이지도 "양식"(웹 양식)이라고 합니다.
셋째, Microsoft는 AJAX를 과도기적 기술로 간주할 수 있습니다.
Microsoft는 웹 사용자 경험을 개선하기 위해 Google 및 기타 회사에서 AJAX 기술을 성공적으로 적용함으로써 AJAX의 급격한 인기를 얻을 때까지 AJAX에 대한 조치를 취하지 않았습니다. 그런 다음 조치를 취하고 AJAX 확장을 ASP.NET에 추가했습니다. 전체적인 과정은 분명 공격적이지 않았고, 리소스도 많이 투자되지 않았습니다. 마이크로소프트와 넷스케이프가 브라우저 전쟁을 벌였을 때와는 전혀 달랐습니다. 그러나 VS2008에 AJAX Extension을 표준 구성으로 내장하고 JavaScript 디버깅 기능을 IDE에 직접 통합했다는 사실은 Microsoft가 여전히 현실에 직면하고 있으며 AJAX가 중요한 위치와 큰 개발 잠재력을 가지고 있음을 인식하고 있음을 보여줍니다.
실제로 마이크로소프트의 야심은 '세계 통일', 브라우저를 버리고 B/S와 C/S를 완전히 통합하는 것이라고 분석한다.
이는 .NET 3.0/3.5에서 명확하게 나타납니다.
우선, Microsoft는 WCF를 사용하여 DCOM, .NET Remoting 및 C/S에 주로 사용되는 기타 기술을 통합했으며, 원래 COM+에 있던 많은 엔터프라이즈 개발 기능과 B/S 아키텍처에 주로 사용되는 웹 서비스 기술을 통합하여 통합 Abstract를 만들었습니다. 재사용 가능한 WCF 서비스로 캡슐화합니다. Microsoft가 정보 시스템 개발 모델을 CBD에서 SOA로 변경하기를 원하는 것은 분명합니다(즉, 미래의 시스템은 구성 요소 대신 서비스를 조립할 것입니다).
둘째, Microsoft는 매우 성숙한 Window 데스크톱 프로그래밍 모델(Win32 API + 메시지/이벤트 기반)을 포기하고 새로운 WPF 프로그래밍 프레임워크를 도입했습니다. 주요 혁신 중 하나는 XML 사양을 준수하는 XAML(Application Markup Language)의 출현입니다. . XAML은 XML 형식의 일반 텍스트 파일을 사용하여 애플리케이션 인터페이스를 설명합니다.
XAML과 XHTML을 쉽게 비교할 수 있습니다. 브라우저는 XHTML 코드를 구문 분석하여 시각적 웹 인터페이스를 생성하는 반면, XAML은 .NET Framework 가상 머신에 의해 구문 분석됩니다. Vista에서는 Vista가 .NET Framework 3.0을 직접 통합하므로 읽기를 담당한다고 할 수 있습니다. XAML은 사용자 인터페이스를 생성하고 모든 애플리케이션 기능을 구현합니다.
결과적으로 새로운 프로그래밍 모델이 등장했습니다. B/S 시스템이든 C/S 시스템이든 XAML 코드 읽기 → 구문 분석 → 현재 → 사용자 입력 수신 → 프로세스 데이터 → 결과 표시라는 방식이 통일되었습니다.
이 프로그래밍 모델에서 브라우저는 방관자가 되며 더 이상 클라이언트 애플리케이션의 핵심이 아닙니다.
새로운 프로그래밍 모델은 기능이 제한된 브라우저가 아닌 모든 기능을 갖춘 OS에서 실행됩니다. 이 차이는 엄청납니다. OS에서 실행되는 브라우저의 기능을 OS 자체의 기능과 어떻게 비교할 수 있습니까?
이제 객체지향적으로 구성된 운영체제 API(Application Programing Interface)를 통해 운영체제의 다양한 기능을 쉽게 호출할 수 있으며, 클라이언트의 하드웨어 자원을 최대한 활용할 수 있습니다. .NET Framework 프로그램, 듀얼 코어 CPU의 작업 기능을 "압착"합니다. 사용자 인터페이스는 모두 B/S와 C/S의 인터페이스 계층 기술을 통합한 XAML을 사용하여 설명됩니다.
WPF에 가장 적합한 실행 환경은 Vista 운영 체제(현재 Silverlight라고 함)가 브라우저 플러그인으로 구현되어 WPF 프로그램이 기존 브라우저에서 실행될 수 있도록 해줍니다. Silverlight와 Vista 모두 XAML 자체를 구문 분석할 수 있으므로 이제 XAML을 사용하여 B/S와 C/S 모두에 적용 가능하고 동일한 사용자 경험을 얻을 수 있는 하나의 인터페이스 코드 세트만 작성할 수 있습니다.
B/S와 AJAX의 고유한 단점으로 인해 AJAX를 통해 강화된 B/S 시스템을 댄서에 비유한다면 실제로는 족쇄를 차고 춤을 추는 댄서이며, Microsoft의 생각은 무게를 가볍게 하려고 끊임없이 노력하는 대신 이 족쇄를, 그냥 버리는 게 어때?
마이크로소프트의 WPF와 WCF 출시가 바로 그러한 시도이다.
마이크로소프트의 개발 전략은 기존 B/S와 C/S의 장단점 분석을 기반으로 하고 있으며, 이는 과학적인 성격을 갖고 있으며, 또한 자체적인 사업적 이익도 고려하고 있다고 해야 할 것이다. 그러나 마이크로소프트만큼 강력하더라도 세계를 장악할 수는 없기 때문에 이 전략을 실현하는 데는 여전히 어려움이 많다. Microsoft의 반대자들은 Microsoft만큼 똑똑하고 그들의 기술도 마찬가지로 빠르게 발전하고 있습니다.
정보시스템 적용의 연속성으로 인해 B/S와 C/S는 장기간(아마도 3~5년, 어쩌면 5~10년) 동안 동시에 공존할 것이라고 결론 내릴 수 있다. 많은 B/S 뛰어난 성능이 C/S와의 경쟁에서 승리할 것이며 이러한 상황은 크게 변하지 않을 것입니다. AJAX의 경우 B/S 시스템의 강력한 무기로서 매우 효과적이긴 하지만 앞으로의 발전에 대해 조심스럽게 낙관하고 있습니다. 그러나 웹 개발자로서 이 기술을 이해하고 적용해야 합니다.
미래 풍경이 어떤 모습일지, 특정 기술에 미래가 있을지 여부는 개인이 결정하는 것이 아닙니다. B/S와 C/S의 싸움의 최종 패턴은 여러 요소들 간의 합동 게임의 결과가 될 것이라고 생각합니다. 개인으로서는 시대에 발맞춰 행동과 전략을 적시에 조정해야 합니다. 이것이 현대 소프트웨어 개발자의 운명입니다.