最近、ある企業では PowerBuilder で開発されたシステムを長年使用しており、古い情報システムを C/S アーキテクチャから一般的な B/S アーキテクチャに変換することにしました。問題が発生しました。元のシステムには、多数のデータ入力、正確なレポート印刷などの機能があり、ユーザーはこの種の操作に非常に慣れています。新しいシステムでもこの使いやすい機能が維持されることが期待されます。オリジナルシステムの。
この質問を聞いてすぐに頭が痛くなりました。PB には強力なコントロールがたくさんあり、それらをブラウザに移動して Web ページを使用してシミュレートするのは難しすぎます。
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 システムはブラウザであり、ハードウェア (プリンタなど) に直接アクセスできないなど、多くの制限があり、十分な機能を発揮できません。ハードウェアリソースの使用。たとえば、今日の新しいコンピューターはすべてデュアルコアです。JavaScript と HTML を直接使用して、これら 2 つの「Pentium コア」を最大限に活用するマルチスレッド プログラムを作成できますか?
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 (アプリケーション プログラミング インターフェイス) を通じて簡単に呼び出すことができます。クライアントのハードウェア リソースを最大限に活用するための機能 (たとえば、.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の戦いの最終パターンは、複数の要素の共闘の結果になると思います。個人は時代に合わせて行動や戦略をタイムリーに調整しなければなりません。これが現代のソフトウェア開発者の宿命です。