1 B/S が優れたユーザー インタラクション エクスペリエンスを提供することが難しいのはなぜですか?
ここでの最大の問題は次のとおりです。
(1) ステートレスな HTTP プロトコル
Windows フォームはメモリを介して直接情報をやり取りできますが、B/S アーキテクチャの通信の基本プロトコルである HTTP はステートレスです。
HTTP プロトコルの管理下で、ブラウザをゲスト、Web サーバーをホテルとみなした場合、この状況が発生します。ゲストが何度訪問しても、Web サーバーはそのゲストを最初のゲストと見なします。時間の訪問者。このように、ホテルスタッフによる「本人確認」のため、宿泊客は毎回身分証明書を持参する必要がある。
HTTP プロトコルのステートレス性は Web サーバーの「無視」につながりますが、これにより Web サーバーのスループットは向上しますが、アプリケーション システムの開発には問題が生じます。アプリケーション システムには多くのビジネス処理プロセスがあり、本質的に情報が流れるためです。つまり、元のデータが一方の端から入力され、もう一方の端から出力されるときに特定の処理が行われるはずであるということは、どのように想像できますか。ビジネスプロセス全体の情報が失われるのでしょうか？したがって、HTTP リクエスト間での情報の共有が厄介になります。これが HTTP リクエストの「状態保持」問題です。すべての B/S システムはこの問題を解決する必要があります。 Microsoft は、HTML Web ページの隠しフィールドを最大限に活用し、Web サーバーでいくつかのトリックを実行するなど、いくつかの「不正なトリック」を考え出しました。そのため、ASP.NET には、各 HTTP リクエスト間の状態を維持するための一連のテクノロジが組み込まれています。セッション、Cookie、ViewState、プロファイル、アプリケーション。
しかし、問題は完全に解決されたわけではありません。たとえば、ユーザーの入力情報を収集する C/S システムの共通ダイアログ ボックスでは、メイン フォームとダイアログ ボックス (モーダルとノンモーダルの 2 種類に分けられます。前者はダイアログ ボックス) の間で情報のやり取りが行われます。 B/S アーキテクチャでは、ブラウザの各リクエストは独立しているため、モーダル ダイアログ ボックスと同様の直接の情報交換を 2 つの独立したブラウザ ウィンドウ間で実装する必要があります。何をすればいいのか分かりません。
AJAX は、次のメソッドを使用してモーダル フォームを「シミュレート」します。つまり、メイン フォームとダイアログ ボックスを 1 つに「結合」します。ダイアログ ボックスは HTML の div 要素であり、通常は非表示になっており、必要に応じて表示されます。 Microsoft の AJAX コントロール ツールキットには、この機能用に設計されたコントロールもあります。 B/S開発にはこのような工夫が無数にあります。
C/S では簡単に実装できる機能の多くが、B/S では実装が非常に難しいことがわかります。
(2) 特殊な動作環境 - ブラウザ
B/S システムのフロントエンド動作環境はブラウザであるため、ハードウェア (プリンタなど) に直接アクセスできないなど、多くの制限があり、ハードウェア リソースを最大限に活用できません。たとえば、今日の新しいコンピューターはすべてデュアルコアです。これら 2 つの「Pentium コア」を最大限に活用するために、JavaScript と HTML を直接使用してマルチスレッド プログラムを作成できますか?
C/S システムは OS (オペレーティングシステム) 上で直接動作し、OS が提供するすべての機能を呼び出すことができます。
(3) 恥ずかしい Web クライアント プログラミング言語 –
従来の C/S プログラムである JavaScript は、多数のさまざまな開発言語、特に C++、Java、C# などの主流のオブジェクト指向言語を使用できます。強力で使いやすく、さまざまな開発ツールが利用可能で、非常に成熟しています。
それどころか、B/S フロントエンドで最も一般的に使用されているプログラミング言語である JavaScript は、「JavaScript を使用したプログラミング」を面倒なことだと考えている多くのプログラマーによって嫌われているだけでなく、「嫌われ」さえしています。
JavaScript の 2 つの主な欠点を見てみましょう。
まず、明確で統一されたプログラミング モデルが不足しています。
JavaScript は名前に Java が含まれており、同様の構文を使用しますが、実際の Java とは何の関係もありません。ああ、彼女はみにくいアヒルの子です。いつも白鳥になりたいと思っていますが、他の人が自分の考えを受け入れてくれないとは思っていません。
JavaScript は多くのオブジェクトを使用しますが、オブジェクト指向であると言うのは非常に説得力がありません (オブジェクト指向プログラミングの基本単位はクラスです)。たとえば、主流のオブジェクト指向言語のようなクラスというキーワードがありません。 C# など、あらゆる場所に関数が 1 つずつ存在するため、すべてのコードをクラスの形式で明確に定義することが困難になると同時に、構造化されていません (構造化プログラミングの基本単位は関数です)。ブラウザーは HTML ドキュメントを解析するときにストリームを使用するため、一部の JavaScript コードは関数の外に配置され、HTML ドキュメントの解析時に直接実行されますが、関数内に配置されたコードの他の部分はほとんどがイベント駆動型で実行されます。この方法は、複雑な問題を引き起こします。プログラムの実行フローは、純粋に構造化されたプログラミングでの関数呼び出しの統一的な使用よりもはるかに簡潔ではありません。
この観点から見ると、JavaScript はオブジェクト指向、構造化、非構造化プログラミング手法の特徴を持っていますが、魚にも鳥にも明確な統一されたプログラミング モデルがありません。構造とメンテナンスのしやすさに多くの混乱が生じました。
次に、JavaScript のもう 1 つの欠点は、ブラウザの実行環境です。
歴史的な理由により、異なるブラウザ、さらには同じブラウザの異なるバージョンでも多かれ少なかれ異なるプログラミング モデルが存在するため、たとえば、ブラウザの種類を検出するコードのセットを記述する必要があります。 IE、および FireFox 用に別のセットを作成しました。これは本当に面倒です。
上記の問題は、ほとんど B/S アーキテクチャ システムの「固有の」「欠陥」です。生まれつきの欠陥は養育によって補われ、人々はこれらの問題を解決するために多くのトリックを考え出してきました。 AJAX は誰もが期待する希望の星です。
2 Star of Hope - AJAX
ここ数日間、私は Microsoft の AJAX フレームワークについて体系的に学びました。このフレームワークの複雑さは、私の当初の予想をはるかに上回っていたことがわかりました。AJAX フレームワークを設計した Microsoft エンジニアは、さまざまな Web 開発テクノロジの可能性を深く調査し、以前に提起された問題を大幅に補いました。
(1) JavaScript 言語の拡張:
Microsoft は、継承、インターフェイスの定義、オブジェクトのシリアル化、イベントのトリガー、リフレクション型などの機能を簡単に実装できる、カプセル化された AJAX ライブラリを提供することで、JavaScript のオブジェクト指向機能を強化しました。オブジェクト指向言語 (Java/C# など) の間にはまだギャップがありますが、「醜い」JavaScript を目に見えるものにドレスアップできることは並外れたものであると考えられます。
(2) AJAX ライブラリのサポートと JavaScript の機能強化により、ブラウザー自体のサポートにより、ブラウザー側のコードの機能が大幅に向上し
、ブラウザーで JavaScript スクリプトを作成して非同期リクエストを簡単に行うことができます。をサーバーに送信し、部分的なページ更新を実現し、Web サービスを直接呼び出すことができます。
(3) コンポーネントベース開発 (CBD) 手法の導入
コンポーネントベース開発 (CBD) は、現在、SOA (サービスベース アーキテクチャ) が非常に宣伝されているものの、長い間主流の開発手法です。 CBDと同じくらい成熟するには時間がかかります。
SOA どころか JavaScript の場合、CBD を実装するのは非常に困難です。
CBD を実現するために、Microsoft は JavaScript を「大幅に改善」し、多くの機能を強化しました。Microsoft AJAX ライブラリに基づいて、プログラマーは 3 種類の再利用可能なコンポーネントを開発できます。 None_Visual コンポーネント (オブジェクト指向システムに相当する、目に見えないコンポーネント)。そのうちの 3 つはパブリック関数を提供します)、Behavior (既存の Web コントロールの機能を拡張する動作)、および Control (ビジュアル インターフェイス要素を備えた Web コントロール) です。
特に、AJAX Control ToolKit で提供される数十のコントロールは、基本的に C/S ユーザー インターフェイスのほとんどの機能の B/S シミュレーションを実現し、この新しいプログラミング モデルを適用するためのモデルです。
Microsoft による JavaScript プログラミング モデルの機能強化により、ソフトウェア エンジニアは最終的に CBD 開発手法を使用して Web クライアント コードを開発できるようになります。これは進歩だと思います。
(4) サーバー側の機能強化
ブラウザ側のコードの機能を強化するには、サーバー側で連携する必要があります。 AJAX 自体は、ブラウザと Web サーバーが相互にサポートするプログラミング モデルに基づいています (Web サーバーはデータ サービスを提供し、ブラウザは Web サーバーに非同期リクエストを行うための XMLHttpRequest オブジェクトを提供します。データが返されると、プログラマーは JavaScript でコードを作成して、 Web ページ更新の動的部分処理を実装します。
Microsoft は、AJAX 拡張機能を通じて、サーバー側の ASP.NET フレームワークの機能を強化しました。また、よく使用される関数を単純な Web コントロール (AJAX のコア コントロール ScriptManager、ページの更新可能な領域を定義する UpdatePanel、既存の ASP.NET コントロール (つまり、ASP.NET コントロールにアタッチされたコントロール) を拡張するための多数の AJAX コントロール ツールキットなど) に外部化します。既存のコントロール (その目的は、新しい機能を既存のコントロールに拡張することです)。
これらのコントロールを使用すると、Web フロントエンド プログラムの開発は VB でのフォームの設計に似ています。 Windows フォームと同様のインターフェイスを描画できるだけでなく、AJAX の非同期リクエストやページの部分更新技術を利用することで、Web サーバーとの連携により、ユーザー エクスペリエンスを Windows フォームに強制適用できるようになりました。
どれほど多くの人が VB を軽視していても、VB によってもたらされたビジュアル プログラミングの普及の波は、Microsoft による JavaScript プログラミングの推進に広範な影響を及ぼしているのは一般的な傾向でもあります。 Web 開発の効率を向上させるには、このステップを実行する必要があります。
ただし、いくら「補充」したとしても、結局は「先天的に欠損」しており、B/SアーキテクチャがユーザーエクスペリエンスにおいてC/Sを超えることは依然として非常に難しいことを指摘する必要があります。 。
3 将来: B/S と C/S、どちらが担当しますか?
管理と展開が簡単なため、今日では B/S アーキテクチャが多くの情報システムの第一の選択肢となっていますが、ユーザーは優れたユーザー エクスペリエンスを追求しています。要約すると、次の要件が必要です。
(1) 美しいインターフェイス。この点ではB/Sが有利です。
(2) 便利な入力。たとえば、多くのユーザーは、マウスを使用せずにデータを入力したり、単純なクリックだけでデータを自動的に入力したりすることを望んでいますが、AJAX アーキテクチャではこの問題をある程度解決できます。
(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 を完全に倒す」ことは不可能です。 。
さらに興味深いのは、Microsoft のような大企業は B/S と C/S の開発の見通しをどのように見ているかということです。
私のような一般の開発者は Microsoft の幹部と直接話す機会がありませんが、同社の製品開発ルートからいくつかのヒントを得ることができます。
Microsoft は、B/S が将来の技術開発の方向性を示しているとは考えていないようです。それどころか、その行動の多くはブラウザを放棄する方向に向かっています。
まず、マイクロソフトは C/S の開発と展開を簡素化し、C/S クライアント プログラムの更新を手動介入なしで自動的に実行できるようにスマート クライアント テクノロジを開始しました。
第二に、マイクロソフトは B/S と C/S の間のギャップを埋めるために懸命に努力し、ASP.NET を設計する際に、良い結果をもたらした ASP を断固として放棄し、同様の「ビジュアル コントロール + イベント駆動型」プログラミング手法を直接採用しました。 VB では Web ページも「フォーム」、つまり Web フォームと呼ばれます。
第三に、Microsoft は AJAX を過渡的なテクノロジとみなす可能性があります。
Microsoft は、Web ユーザー エクスペリエンスを向上させるために Google や他の企業が AJAX テクノロジを適用することに成功したため、AJAX が急速に普及するまで、AJAX への取り組みを開始するのが遅かったのです。その後、AJAX 拡張機能を ASP.NET に追加しました。プロセス全体は明らかに、アクションは積極的ではなく、多くのリソースが投資されたわけではありませんでした。これは、Microsoft と Netscape がブラウザ戦争を開始したときとはまったく異なりました。しかし、VS2008 では AJAX Extension を標準構成として組み込み、JavaScript のデバッグ機能を IDE に直接統合しているという事実は、Microsoft が依然として現実を直視しており、AJAX が重要な位置と大きな発展可能性を持っていることを認識していることを示しています。
実際、マイクロソフトの野望は「世界を統一する」ことであり、ブラウザを捨て、B/SとC/Sを完全に統一することだと私は分析している。
これは .NET 3.0/3.5 で顕著に見られます。
まず、Microsoft は WCF を使用して、主に C/S に使用される DCOM、.NET リモーティング、およびその他のテクノロジを統合し、もともと COM+ にあった多くのエンタープライズ開発機能と、主に B/S アーキテクチャに使用される Web サービス テクノロジを統合して、統一された要約に統合しました。そして再利用可能な WCF サービスにカプセル化します。 Microsoft が情報システム開発モデルを CBD から SOA に変更したいことは明らかです (つまり、将来のシステムはコンポーネントではなくサービスを組み立てることになります)。
第 2 に、Microsoft は非常に成熟した Windows デスクトップ プログラミング モデル (Win32 API + メッセージ/イベント駆動) を放棄し、新しい WPF プログラミング フレームワークを導入しました。主要な革新の 1 つは、XML 仕様に準拠した XAML (Application Markup Language) の登場です。 。 XAML は、XML 形式のプレーン テキスト ファイルを使用してアプリケーション インターフェイスを記述します。
XAML と XHTML を簡単に比較できます。ブラウザは XHTML コードを解析してビジュアルな Web インターフェイスを生成しますが、Vista では .NET Framework 仮想マシンによって解析され、Vista はスーパー ブラウザと見なすことができます。 XAML を使用してユーザー インターフェイスを生成し、そのすべてのアプリケーション機能を実装します。
その結果、B/S システムでも C/S システムでも、XAML コードの読み取り、解析、表示、ユーザー入力の受信、データの処理、結果の表示という方法が統一されました。
このプログラミング モデルでは、ブラウザは傍観者となり、クライアント アプリケーションの中核ではなくなります。
新しいプログラミング モデルは、機能が制限されたブラウザではなく、フル機能の OS 上で実行されます。この違いは非常に大きいです。OS 上で動作するブラウザの機能を OS 自体の機能と比較するとどうなるでしょうか。
オブジェクト指向で整理されたオペレーティング システムの API (Application Programming Interface) を通じて、クライアントのハードウェア リソースを最大限に活用して、オペレーティング システムのさまざまな機能を簡単に呼び出すことができるようになります (たとえば、クライアント上のマルチスレッドを簡単に開発できます)。 .NET Framework プログラムは、デュアルコア CPU の動作能力を「圧迫」します)。ユーザー インターフェイスはすべて、B/S と C/S のインターフェイス層テクノロジを統合する XAML を使用して記述されます。
WPF に最も適した実行環境は Vista オペレーティング システムであり、その機能のサブセットは現在 Silverlight と呼ばれており、ブラウザ プラグインとして実装されており、WPF プログラムを従来のブラウザで実行できます。 Silverlight と Vista はどちらも XAML 自体を解析できるため、XAML を使用して 1 セットのインターフェイス コードのみを作成できます。これは B/S と C/S の両方に適用でき、同じユーザー エクスペリエンスが得られます。
B/S と AJAX には固有のいくつかの欠点があるため、AJAX によって強化された B/S システムをダンサーに例えると、それは実際には足かせを付けられて踊るダンサーであり、マイクロソフトの考えは、常に重量を軽くしようとするのではなく、この足かせ、捨てたらどうですか？
Microsoft の WPF および WCF の立ち上げは、そのような試みです。
マイクロソフトの開発戦略は、既存の B/S と C/S の長所と短所の分析に基づいており、その科学的な性質を持ち、自社のビジネス上の利益も考慮に入れられています。しかし、Microsoft のように強力であっても世界を支配することはできないため、この戦略を実現するには依然として多くの困難があります。 Microsoft の敵対者は Microsoft と同じくらい賢く、彼らのテクノロジーも同様に急速に進歩しています。
情報システムアプリケーションの継続性により、B/S と C/S は長期間 (おそらく 3 ～ 5 年、おそらく 5 ～ 10 年) にわたって共存すると結論付けることができます。 B/S に優れた優れた機能が多く、C/S との競争ではこの状況は大きく変わらない。 AJAX については、B/S システムの強力な武器として非常に効果的ですが、多くの欠点がありますが、Web 開発者としては、このテクノロジを理解して適用する必要があります。
将来の景色がどのようになるか、特定のテクノロジーに将来性があるかどうかは、個人が決めるものではありません。 B/SとC/Sの戦いの最終パターンは、複数の要素の共闘の結果になると思います。個人は時代に合わせて行動や戦略をタイムリーに調整しなければなりません。これが現代のソフトウェア開発者の宿命です。