ASP.NET と支柱: Web アプリケーション アーキテクチャ
M. キース・モルテンセン 、注入開発
Rob McGovern、 注入開発
Charles Liptaak、Microsoft Corporation
2003 年 12 月
適用対象:
Microsoft® ASP.NET
[Microsoft .NET Framework]
ジャカルタ・ストラット
概要：.NET Framework上の ASP.NET と Java 2 Enterprise Editionのストラットの類似点と相違点、および開発者の一般的な問題を解決するための機能について説明します。 それぞれの長所と短所、および次世代の Web 開発に使用するユーティリティについて説明します。 (26ページ印刷)
内容
はじめに
プラットフォームの概要
Web Framework Parallels
フレームワーク パターン
楽しみ
支柱と J2EE アプリケーションを ASP.NET に移行する
概要と結論
補遺
はじめに
過去 10 年間で、ビジネスを行い、情報にアクセスする方法が変わりました。 90年代初頭にシンプルな情報ポータルが登場して以来、インターネットは急速にビジネスと貿易のための主要で収益性の高いフォーラムに進化してきました。 この進化により、エンタープライズ Web アプリケーションを構築するための 2 つの主要な標準が生み出されました。Microsoft® ASP.NET (および Microsoft .NET Framework) と Apache の支柱 (J2EE フレームワークと共)。
.NET コミュニティと Java コミュニティの両方のアーキテクトと開発者は、スコープ、機能、および基になるアーキテクチャでこれら 2 つのテクノロジがどのように比較されるかを尋ねられています。 このペーパーでは、プラットフォームの概要、類似点と相違点の概要、および各フレームワークが開発者の一般的な問題を解決するために提供する機能のレビューについて説明します。 ASP.NET とStrstrsに実装されている業界標準のパターンが、コードの複雑さを軽減し、開発時間を短縮するのにどのように役立ったかを示します。 また、各オファリングの長所と短所、および次世代の開発にもたらす有用性についても説明します。
Web 開発の簡単な進化の歴史
Web の初期の頃、ほとんどのビジネス Web サイトは単に広告の形式であり、ユーザーマニュアル、パンフレット、カタログをお客様に提供していました。 ドットコム革命は、顧客にオンライン サービスを提供できる企業を示しました。 今では、在庫を表示するだけではなく、顧客が購入することもできます。 この進化の新しいフェーズによって、多くの新しい要件が生み出されました。 Web サイトは、信頼性が高く、使用可能で、セキュリティで保護され、可能であれば高速である必要がありました。
これらの初期の e コマース Web サイトは、多くの場合、JSP、EJB、サーブレット、JDBC などの Java ベースのテクノロジを利用していました。または、ASP、VBScript、MTS、ADO、COM、COM+ を含む Microsoft ベースのテクノロジ。 これらのテクノロジは機能しましたが、ほとんどのサイトは、スケーラビリティ、信頼性、セキュリティについてあまり考えずに迅速に構築されました。
Java 2 Enterprise Edition
90年代の終わりに向かって、ドットコム現象は完全に力を発揮しました。 しかし、双方の建築家は、Web開発の自然な進化は、使用されていた技術のミシュマッシュの標準化によってのみ達成されることを認識しました。
1999年の春、SunはJ2EE標準をリリースし、多数の異なるJavaテクノロジを単一のバナーの下に統一しました。 この標準化により、多くのサードパーティ企業は、J2EE アプリケーションの構築に特化したツールを開発し、エンタープライズ Web 開発プロセスを大幅に高速化することができました。
しかし、J2EE規格が登場しても、いくつかの重要な問題が残りました。 特に、新しく改善された Web アプリケーションは、多くの場合、バックエンドの順序付け、処理、課金システムと統合できませんでした。 フロントエンドは十分に設計され、スケーラブルでしたが、バックエンドのビジネス ロジックとデータ永続化が Web からの新しい注文の流入をサポートするように設計されていなかったため、システムはまだ中断されました。 より統合されたビジネス ツールと Web サービスの必要性が明らかになりました。 さらに、もう 1 つの傾向が明らかになってきています。アプリケーションの規模が大きいほど、保守と拡張が難しくなっていました。 信頼性の高いスケーラブルなアプリケーションのコード ベースは、非常に複雑になり、管理が困難になっていました。
この背景は、J2EE のパターン革命のフレームワークを構築しました。 開発者やアーキテクトは、これらの確立されたテクノロジに基づいて構築されたシステムを設計し、複雑さの問題を回避するにはどうすればよいですか?
ASP.NET の原点
同じ期間に、Microsoft は別のコースを追求することを決定し、単に別の名前で再グループ化するのではなく、テクノロジを再設計することを選択しました。 Microsoft は、完全に統合された環境を作成することにしました。 その結果、Microsoft .NET Frameworkは、以前のアプリケーション モデルから抜本的に移行しました。 コードの複雑さに対処するために、この新しい柔軟なフレームワークはモデル ビュー コントローラー (MVC) 設計パターンを自然に組み込み、Web サービスの新しいパラダイムをサポートするためにインターネット (HTML、XML、SOAP) のオープン標準を中心に構築されました。 リエンジニアリング プロセスでは、セキュリティ、パフォーマンス、可用性、信頼性、保守性、拡張性、相互運用性などの主要なエンタープライズ要件に大きな注意が払われました。
パターンの回転が J2EE に達する
2000 年の春、Bill Gates と Steve Ballmer が .NET を発表する頃、Craig McClanahan は、Java プラットフォーム上のエンタープライズ規模の Web アプリケーションのコードの複雑さを軽減するために、ストラット プロジェクトに取り組み始めました。 Struts 拡張機能は、モデル ビュー コントローラー (MVC) パターンの実装であり、基本的にフロント コントローラーとインターセプト フィルター パターンをこれらの端に利用します。 MVC 実装の違いについては、このペーパーの後半で説明します。
Web アプリケーションの 3 番目の年齢
現時点では、ASP.NET と支柱は、日常的な開発の問題に強力な解決策を提供するためにステージを取っています。 提供するエンタープライズ アプリケーション フレームワークは、非常に貴重であることが証明されており、企業の開発サイクルが短く、信頼性が高いことを確認します。 J2EE プラットフォームと .NET プラットフォームの背後にはテクノロジと手法の両方に大きな違いが残されていますが、ASP.NET とStrstrs は過去の Web 開発を産業前の労働のように見せかけています。
プラットフォームの概要
.NET と Struts/J2EE の開発環境と実行環境には、多くの類似点といくつかの大きな違いがあります。 図 1 は、2 つの環境が相互にどのように関係するかを示しています。
.gif "Aa478961.aspnet-aspnet-j2ee-struts-01(en-us,MSDN.10).gif")
図 1. ASP.NET と J2EE (支柱付き) プラットフォーム スタック
次のセクションでは、各領域の主な類似点と相違点について説明します。
言語と IDE
言語と開発環境スタックの主な違いは、哲学的な違いです。 J2EE では、1 つの言語 (Java) に制限されていますが、さまざまな開発環境から選択できます。 各 IDE では、言語と Web ツールキットに対して異なるレベルのサポートが提供されます。 たとえば、キーワード (keyword)色分けされた単純なテキスト エディターや、デバッグをサポートする完全な環境で作業できます。 当然ながら、IDE と他のコンポーネント (OS、アプリケーション サーバーなど) の統合レベルは、ベンダーによって大きく依存します。
ASP.NET では、開発言語には多くの選択肢がありますが、開発環境の主な選択肢の 1 つです。 テキスト エディターで ASP.NET を開発することはできますが、軽量の Web マトリックス製品または他のサードパーティ 製エディターを使用して開発できますが、プライマリ開発環境は Microsoft Visual Studio® .NET です。 Visual Studio .NET は、コンソール、ワイヤレス、Web、Web サービス、Windows アプリケーションの開発だけでなく、Biztalk® Server 2004、Office 2003、コンテンツ管理サーバーなどの他の Microsoft 製品の IDE としても機能する非常に高度な IDE です。 これにより、Visual Studio .NET は高度に活用された環境になり、長期的に継続的な改善と進化が保証されます。 サード パーティのツール開発者は、IDE を活用し、Visual Studio .NET 内で実行されるツールを作成することもできます。 たとえば、Crystal Reports と Rational XDE には、Visual Studio .NET にモジュールが組み込まれており、これらの製品に特に関連する .NET 開発を高速化します。 このレベルの統合により、Visual Studio .NET は非常に強力な開発ツールになります。
アプリケーション サーバーとオペレーティング システム
J2EE と.NET Frameworkはどちらも、Web アプリケーションをホストし、重要なサービスを提供するために 1 つ以上のサーバーに依存しています。 これらのサーバーとランタイム自体も、基本オペレーティング システムに依存します。
J2EE フレームワークは、プラットフォームに依存するように設計されています。 そのため、多くのベンダーは、さまざまなオペレーティング システムで実行される J2EE アプリケーション サーバーを構築しています。 プラットフォームの独立は重要ですが、オーバーヘッドと複雑さが大幅に増加します。 複数のオペレーティング システム (OS) をサポートするために必要な抽象化レイヤーでは、アクセスできる OS 機能の数に対する制限が強制されます。 ベンダーごとに異なるレベルの統合が提供される場合があり、選択したアプリケーション サーバーと実行するオペレーティング システムによってパフォーマンスが大きく異なる場合があります。 最後に、ベンダーを混在させることで、各ベンダーのアップグレード/パッチ サイクルを監視する必要があり、ベンダーによる変更を他のすべての製品に対してチェックする必要があり、多くの場合、サポートが複雑になります。 プラットフォームの独立は利点ですが、関連するコストがあります。
アプリケーション サーバーが OS から完全に独立している J2EE とは異なり、.NET アプリケーション サーバーは Microsoft Windows オペレーティング システム (および Windows® によって提供されるサービス) です。 .NET Frameworkは、IIS および COM+ と緊密に統合して、信頼性の高いアプリケーション ホスティング サービスと、XML、SOAP、UDDI、WSDL などの Web サービス標準のネイティブ サポートを提供するように設計されました。 この統合により、.NET アプリケーションのパフォーマンスが大幅に向上しますが、プラットフォームの一夫一婦制が必要です。 統合のレベルは J2EE サーバーよりもはるかに厳しく、より多くの機能と高速なパフォーマンスが得られます。
Runtimes
J2EE と.NET Frameworkの両方がランタイム エンジン上で実行されます。 ランタイムはコードを解釈してコンパイルし、メモリ管理などの重要なサービスを提供します。 2 つのランタイムの目標は、設計哲学の違いにより大きく異なります。
Java ランタイムは、オペレーティング システム間の移植性のために設計されました。 これは移植性が必要な状況では有利ですが、コードは特定のオペレーティング システムまたはアプリケーション サーバーではなく、実行専用に最適化できるため、アプリケーションのパフォーマンスが制限されます。 サードパーティ製品は、多くの場合、移植性を犠牲にして OS 固有の最適化を提供するために導入されます。
一方、共通言語ランタイム (CLR) は、Windows オペレーティング システムでのパフォーマンスの最適化と複数のプログラミング言語のサポートという 2 つの目的で設計されました。 CLR は、共通の型システムを介して任意の数の異なるプログラミング言語をサポートし、オペレーティング システムの変更からアプリケーションを分離するのに役立ちます。
クラス ライブラリ
ストラットは、約 135 個のパッケージを持つ J2EE クラス ライブラリと J2SE クラス ライブラリの両方に大きく依存し、さまざまな基本パッケージ グループ (java、javaxおよび org) に沿って分割されます。 ストラットフレームワークは、ストラットの働きに固有の新しい基底クラスを通じて機能を組み込むために、ライブラリセットをわずかに広げる。 J2EE および J2SE ライブラリは完全に機能しますが、ライブラリの継続的な拡張 (J2EE ライブラリはバージョン 1.2 以降で 2 倍以上) により、複雑さと難読化された機能が追加され、それ以外の場合は直感的である必要があります。 たとえば、XML アクセスに または を使用org.xmlするタイミング、または をリモート メソッドの機能に使用org.omg.stub.java.rmijava.rmijavax.rmi するタイミングを決定することは、必ずしも明らかであるとは限りません。java.xml 一部のライブラリは互換性のためにバージョンに基づいて分離されていますが、順序はあまり意味をなせず、初心者にとって直感的ではありません。
.NET Frameworkは、豊富で広範な基底クラス ライブラリ (BCL) を提供します。 クラスは、パッケージに似た論理グループである機能名前空間によって編成されます。 たとえば、System.Web.UI には、Web のユーザー インターフェイスのすべてのクラスが含まれます。 クラスにはSystem.Web.UI.Page、ASP.NET ページに必要なメソッドとプロパティが含まれています。 .NET Framework (1.1) BCL には、200 を超えるコア(System.*)名前空間が含まれています。
バージョン管理
Java プラットフォームと.NET Frameworkの主な違いの 1 つは、.NET には、.NET Frameworkとフレームワーク上に構築されたアプリケーションの両方に適用される固有の厳密に適用されたバージョン管理スキームがある点です。 Java では、フレームワークのバージョンはドキュメントに記載されており、特別な "非推奨" タグによって部分的にのみ適用されます。 多くの場合、下位互換性を確保するために新しい Java パッケージが作成されます。 Web デプロイ記述子の XML タグを使用して、アプリケーション レベルで追加のバージョン管理を使用できます。 ただし、バージョン管理システムは厳密に適用されておらず、サイド バイ サイドデプロイの制御は困難です。
.NET では、.NET Frameworkがバージョン識別を処理する方法が原因で、バージョン管理の問題ははるかに少なくなります。 BCL 内の各アセンブリには、バージョン番号を含む厳密な名前が付けられているため、異なるバージョンが競合することなく並べて実行される可能性があります。 言い換えると、.NET の新しいバージョンでは、既存のクラスを変更するために新しい名前空間を含める必要はありません。 アセンブリの両方のバージョンをコンピューターに読み込むことができます。CLR は、コンパイル対象のライブラリのバージョンにアプリケーションを自動的にバインドします。 アプリケーションを新しいバージョンにリダイレクトする場合は、グラフィカル ツールまたはコマンド ライン ツールを使用してリダイレクトを構成できます。 同じシステムがアプリケーション レベルで使用されます。 つまり、すべてのアセンブリに厳密な名前で署名し、CLR によって適用されるバージョン管理を利用できます。
Web コンポーネント
J2EE と.NET Frameworkはどちらも、豊富な Web アプリケーション テクノロジを提供します。 J2EE では、サーブレット、JavaServer Pages、タグ ライブラリを選択できます。 ブラウザー検出を実行し、ブラウザー固有の出力を生成するために、多くのタグ ライブラリ セットが作成されています。 ただし、現在、ブラウザー検出は J2EE フレームワークに組み込まれていません。 JavaServer Faces 仕様では、今後この機能が提供される可能性があります。
.NET 側では、Web アプリケーションは ASP.NET を使用して構築されます。 ASP.NET ページには、テキスト ボックス、ボタン、その他のフォーム要素などの機能をカプセル化するグラフィカルな "ドラッグ アンド ドロップ" コンポーネントである Web コントロールが含まれています。 Web コントロールは、ブラウザーの検出や自動生成など、豊富な機能セットを提供します。 開発者は、既存の Web コントロールを拡張したり、新しい Web コントロールを記述したりして、カスタム機能を実行することもできます。
データ アクセス
J2EE Framework と.NET Frameworkの両方にデータ アクセス ライブラリが含まれています。 各ライブラリのコア機能では、同様の直接データベース アクセス (コマンドの送信や結果の受信など) が可能ですが、拡張機能と基本的なパラダイムは大きく異なります。
コア Java JDBC ライブラリは、データベース アクセスに対する非常に従来のアプローチをサポートしています。 ユーザーはステートメント (通常はクエリまたはストアド プロシージャ呼び出し) を送信し、データベースへのライブ接続を使用して結果セットの形式で結果を受け取る場合があります。 データベースの呼び出しと結果は、常に開いている接続によって異なります。 いくつかの高度なクラスでは、切断されたデータ セットがサポートされていますが、JDBC ライブラリは、Web アプリケーションで非常に一般的な断続的な接続シナリオ用に構築されていませんでした。 さらに、JDBC は XML データの読み取りまたは書き込みを直接サポートしていません。 XML ベースのデータベース アクセス用に複数のベンダーが JDBC ラッパーを作成していますが、コア J2EE クラスではサポートされていません。
ADO.NET、ADO や JDBC と同じ機能を提供できる一方で、切断されたパラダイムに基づいています。 データベースから取得されたデータは DataSet と呼ばれるオブジェクトに配置され、データベースへの接続は閉じられます。 その後、DataSet 内のデータにアクセスし、ライブ データベース接続なしで操作できます。 変更が完了すると、DataSet を 1 回の瞬間トランザクションとして ADO.NET を介してデータベースと同期し直すことができます。 この切断された動作は非常に有利で効率的であり、多くの場合、Web アプリケーションなどの分散環境を処理する場合に不可欠です。
ADO.NET は、XML を操作するように設計されています。 データ セット ADO.NET 自動的に XML に変換できるだけでなく、データ セットに基づいて XML スキーマを抽象化することもできます。 これらの機能は、Web サービスやその他の XML ベースのデータ配信メカニズムに特に役立ちます。
Web Framework の並列
インターネットの進化の課題に対処するために、.NET と J2EE の両方が、一般的なアプリケーションの問題に対処するためのフレームワーク コンポーネントを作成しました。 ASP.NET とストラットは、これらのコンポーネントを拡張し、より堅牢な Web 開発メカニズムに貢献します。 この次のセクションでは、検証、キャッシュ、状態管理、セキュリティ、構成、国際化、トレース/インストルメンテーションに焦点を当てて、さまざまなフレームワーク コンポーネントを比較します。
検証
ほぼすべての重要なアプリケーションでは、ユーザー入力に何らかの形式の検証が必要です。 データ検証がないと、アプリケーションは多数の攻撃に対して開かれているので、簡単に中断する可能性があります (たとえば、ユーザーは数値を期待するフィールドに 「数値ではない」と入力します)。 ユーザー入力を検証すると、一般的な問題を防ぐだけでなく、アプリケーションのセキュリティも向上します。
支柱と ASP.NET はどちらも、ユーザー入力を評価し、検証ロジックの実装を高速化するための包括的な検証構造を提供します。 ただし、各フレームワークは非常に異なる方法で問題にアプローチし、同様の結果を生成しますが、独自のソリューションとツールセットを生成します。
支柱検証ツール
ストラット1.1の時点で、ストラットフレームワークには ストラット検証ツールが含まれています。 Validator は、XML ファイルを使用して構成できる新しいデータ フォーム スーパー クラスです。 XML ファイルには、データ型 (整数や文字列など) や文字列形式 (メール アドレス、クレジット カード番号など) などの標準検証の規則が含まれています。 基本的なルールは簡単にカスタマイズでき、新しいルールを追加できます。 検証を必要とするすべてのフォーム アクションは、Struts 検証コントロールから継承する必要があり、XML の書式ルールは正規表現の形式である必要があります。 フォームが送信されると、無効な値とエラー メッセージがビューに返されます。このビューには、検証エラー メッセージを表示するカスタム コードが記述されている必要があります。
シュラット フォームに検証を追加するには、フォーム クラスを書き直し、XML ファイルを編集し、ユーザーに検証エラー メッセージを表示する JSP コードを記述する必要があります。 そのため、最初の設計時に検証を追加することをお勧めします。 既存のアプリケーションに検証を追加するには、継承ツリーを変更する必要があり、アプリケーションが壊れる可能性があります。
ASP.NET 検証コントロール
ASP.NET で検証を構成するには、デザイン時にサーバー側コントロールをページにドラッグ アンド ドロップし、コントロールにいくつかのプロパティを設定するだけです。 ASP.NET には、必要なフィールドのチェック、値の比較、範囲の検証、パターン マッチングのためのすぐに使用できる検証コントロールが用意されています。 パターンマッチング コントロールには、標準的な正規表現チェック (電話番号やメール アドレスなど) の広範なライブラリが含まれており、任意の正規表現を使用するように構成できます。 検証はプログラムで行うこともできますが、適切なイベントを作成して検証コントロールを手動で呼び出すには、もう少し時間がかかります。
これらの検証コントロールはすべてサーバー側のコントロール (つまり、サーバー上で実行) ですが、各コントロールは、クライアント側の検証も実行するように自動的に構成されます。 クライアント側の検証を使用すると、処理のためにページをサーバーに送信することなく、ユーザーは自分のアクションに関するフィードバックをすぐに受け取ることができます。 実際、ページ上のすべてのエラーが修正されるまで、ユーザーはページをサーバーにポストバックできません。 コンパイル時 ASP.NET、クライアント側の検証を実行するために必要な JavaScript が自動的に生成されます (ブラウザーがインターネット エクスプローラー 4.0 以上の場合は、検証はサーバー側のままです)。 クライアント側の検証が実行されたかどうか (または方法) に関係なく、ページ スプーフィング攻撃を防ぐために、フォームを受信した後もサーバー側の検証が実行されます。
キャッシュ
Web アプリケーションでは、クライアント のアクセス時間を短縮するためにキャッシュを使用することが多くなります。 ストラットでは、コンテンツのキャッシュは開発者、または JCACHE などのサードパーティのキャッシュ システムに任されます。 言い換えると、開発者はカスタム キャッシュ システムを構築するか、サードパーティ製品を任意のアプリケーションに統合する必要があります。 多くの場合、開発者はキャッシュ機能をカスタム タグ ライブラリに組み込みます。 一部の J2EE サーバーではネイティブ キャッシュ機能が提供されていますが、Java コミュニティはまだ標準のキャッシュ インターフェイスを開発していません。 今後、J2EE タイル機能は、ページおよびオブジェクト レベルのキャッシュ用の組み込みシステムを提供します。
ただし、ASP.NET には、オブジェクト レベルのキャッシュ (コード オブジェクトの格納)、入力パラメーターベースのキャッシュ (入力パラメーターに基づく動的ページの格納)、時間ベースのキャッシュ (指定された時間のコンテンツの格納) など、多数の組み込みキャッシュ関数があります。 ニーズに応じて、データ オブジェクトまたは動的ページ全体をキャッシュできます。 ディスプレイがユーザー入力に依存していても、実際の表示が頻繁に変更される頻度が低い場合は、HTTP 要求からの入力パラメーターに基づいてページをキャッシュすることもできます。 つまり、製品 ID に依存する製品ページをキャッシュできます。 ASP.NET は、要求された入力パラメーター (製品) ごとに 1 ページを自動的にキャッシュします。 同じ製品に対する後続の要求は、キャッシュされたページを最初から再生成するのではなく、プルします。 すべての ASP.NET キャッシュ メカニズムは、属性を使用して宣言的に構成できます (つまり、コーディングは必要ありません)。 または、単純な API を使用してプログラムでキャッシュにアクセスすることもできます。 ASP.NET キャッシュ システムには、ユーザーの応答を向上させ、静的または半静的コンテンツのアクセス時間を短縮するための幅広いオプションが用意されています。
状態管理
状態管理を使用すると、Web アプリケーションは、複数の Web 要求/応答サイクル中にユーザーとユーザーのデータの両方を追跡できます。 状態管理は、クライアント側 (Cookie や非表示フィールドなど) またはサーバー (Session オブジェクトなど) で実行できます。 ただし、クライアント側とサーバー側の両方の状態管理には、要求間でユーザーを識別するためのメカニズムが必要です。 このメカニズムは、通常、URL に埋め込まれた Cookie またはセッション ID で構成されます。
サーバー側
支柱と ASP.NET はどちらも、要求間の状態を維持するために、同様のホストされたオブジェクト (セッションとアプリケーション) に依存しています。 ただし、ASP.NET では、セッション情報を格納するための 3 つの個別のメカニズムが用意されています。
- メモリ内 — このオプションを選択した場合、状態は要求を受け取るマシン上のメモリに格納されます。 これは、単一のサーバーで実行される小規模なアプリケーションでは問題ありませんが、同じユーザーからの後続の要求が同じサーバー上で行われるという保証はないため、Web ファームでは受け入れ可能なソリューションではありません。
- Session-State ストア - Web ファームでセッション状態を使用するには、状態ストアと呼ばれるものを使用できます。 この状態ストアは、Web ファームのいずれかのメンバーに設定されます。 これは基本的に、ローカルまたは Web ファームの他のメンバーから呼び出すことができるサービスです。 Web ファームのすべてのメンバーは、この中央状態ストアを操作するように構成する必要があり、ここからセッション情報を格納/取得します。 これはセッション状態を格納する非常に効率的な方法ですが、防弾ではありません。 状態ストアをホストしているマシンがクラッシュすると、すべての状態情報が失われます。これはメモリにのみ格納されるためです。
- データベース— セッション状態を格納する最も堅牢で信頼性の高い方法は、データベース内にあります。 Visual Studio .NET には、Microsoft SQL™ Server で状態ストアを設定するためのデータベース スクリプトが用意されています。
同様の機能は一部の J2EE ベンダーによって提供されますが、これらの機能は J2EE またはStrstrs フレームワークに固有ではありません。
クライアント側
クライアント側では、Struts と ASP.NET フレームワークの両方が Cookie と非表示フィールドを使用して、各要求でユーザーを識別して状態を維持します。 ただし、Struts フレームワークは、ID を管理するために J2EE アプリケーション サーバーに完全に依存しており、各サーバーの動作が異なる場合があります。 追加の状態は、開発者が非表示フィールドとして手動でエンコードするか、カスタム Cookie で削除する必要があります。
J2EE とは対照的に、ASP.NET フレームワークには、Cookie と非表示フィールドを使用してクライアント ID を自動的に管理する 1 つのメカニズムがあり、これを使いやすいプログラミング インターフェイスを使用して開発者に公開します。 Cookie はコレクションに格納され、開発者は通常のコレクション処理構文を使用できます。 ASP.NET では、cookieless セッション状態もサポートされています。これはアプリケーションの構成ファイルを介して構成でき、クエリ文字列を使用して要求間でセッション ID を保持します。
ASP.NET では、View State プロパティの形式でクライアント側の状態管理の一意の形式も提供されます。 View State は各 ASP.NET コントロールのプロパティであり、サーバーへのラウンド トリップ間のコントロールの値を保持するために使用できます。 このストレージにより、複数の要求間でのユーザー入力の保持が非常に簡単になります。 ただし、開発者は、すべてのコントロールにビューステート プロパティがあり、必要かどうかにかかわらず、その値が設定されることを念頭に置く必要があります。 ビュー ステートは非表示フィールドとして実装され、すべての要求でクライアントに送信されるため、実際にメモリを必要とするフィールドに対してのみ有効になっていることを確認する必要があります。
セキュリティ
セキュリティは、設計から開発、デプロイ、毎日の使用まで、アプリケーションのすべての段階で重要な役割を果たします。 ストラットは、JSP/サーブレットおよびJ2EEフレームワークに組み込まれているセキュリティに依存するため、特定のセキュリティ機能を提供しません。 J2EE フレームワークでは、基本認証と承認サービスが提供されます。ただし、正確な実装は多くの場合、J2EE サーバーに依存します。 一方、.NET Framework、特に ASP.NET では、認証や承認などの単純なタスク以上の高度なセキュリティ機能が多数用意されています。
認証
すぐに使用 ASP.NET、Windows、Microsoft Passport、およびフォーム認証が提供されます。 Windows および Passport 認証は、ASP.NET ランタイムの外部で実行され、このペーパーの範囲外です。
フォーム認証は、認証されていない要求 ASP.NET ログイン フォームにリダイレクトするメカニズムです。 ユーザー指定の資格情報が検証されると、ユーザーは最初に要求されたページに戻ります。 後続の要求は、ユーザーにメッセージを表示せずに自動的に認証されます。 単純なアプリケーションの場合、ユーザー資格情報は、ASP.NET アプリケーションの構成ファイル内のユーザー、ロール、および承認エントリに対して認証できます。 より複雑なアプリケーションの場合、通常、フォーム認証は外部資格情報ストアを使用するように拡張されます (「フォーム認証の拡張」を参照)。
承認
ユーザーが認証されると、URL 承認によって、要求されたリソースへのアクセス権を付与するかどうかを決定します。 URL 承認は完全に構成ベースであり、アプリケーションの構成ファイル内のエントリを使用して、どのユーザー/ロールがどのリソースにアクセスできるかを決定します。 承認は、完全なRole-Based セキュリティ モデルに簡単に拡張できます。
偽装
偽装を使用すると、ASP.NET アプリケーションは、ページを要求したユーザーの ID を使用して実行できます。 偽装は認証と承認を IIS にプッシュします。ASP.NET は、認証されているかどうかに関係なく、IIS から受信したトークンのみを使用するためです。 偽装する場合、ASP.NET は、特定のリソースへのアクセスを許可または拒否する必要があるかどうかを判断するために、ファイルとフォルダーに対する標準的な NTFS アクセス許可に依存します。
構成
支柱と ASP.NET はどちらも高度に構成可能であり、アプリケーション設定用の一元化された XML ベースの構成ファイルを持っています。 一部の J2EE アプリケーション サーバーでは、XML ベースのサーバー構成もサポートされています。 ただし、各 J2EE ベンダーには、サーバー構成とアプリケーション構成の読み取りタイミングと方法に関して異なるメカニズムがあります。 J2EE は非常に多くの異なる構成ファイル (struts-config.xml、web.xml、サーバー構成ファイルなど) を使用するため、構成のデバッグは非常に困難な場合があります。 また、J2EE アプリケーションには、構成ファイルを読み取るための共通メカニズムがありません。 一部の ServletContextオブジェクト (など) は自動アクセスを持ちますが、他のオブジェクト (ストラット コントローラーなど) にはカスタム コードが必要です。
一方、ASP.NET には、アプリケーションごとに 1 つの XML ファイルがあり、マシン全体に 1 つの XML ファイルがあります。 すべての ASP.NET ページは、アプリケーション レベルの XML ファイルに格納されているすべてのものにネイティブ アクセスできます。 この簡略化された構成構造は、デバッグとアクセスがはるかに簡単です。 さらに、ASP.NET は構成ファイルに対する変更を自動的に取得し、その場でそれらを適用します。 ランタイムは、構成ファイルの変更を検出すると、受信要求をキューに保持し、ASP.NET ワーカー プロセスをリサイクルして新しい構成を読み込みます。 要求は失われず、プロセスは非常に迅速です。 一部の J2EE サーバーはこのように動作しますが、多くの場合、構成の変更を取得するために完全な再起動が必要です。
国際化
あらゆるサイトに国際書式と言語機能を提供するには、かなりの労力が必要です。 テキストの各部分を評価する必要があるだけでなく、表示される各データ (価格や住所情報など)、各画像、場合によってはアプリケーション全体の配色も評価する必要があります。 幸いなことに、スラットと ASP.NET の両方が、国際化の取り組みに役立つフレームワークを提供しています。
一般に、ストラットと Java では、ユーザーの地理的な場所と言語はロケールとして定義されます。 ロケールは他のクラスに渡され、ユーザーの国の適切な形式に情報を解析するために使用されます。 その言語と場所のペアの単語、フレーズ、画像は、キー値ペアのリソース バンドルに格納されます。 "greeting" などのキーワードは、US-Englishロケールで "hello world!" としてマップするか、DK-Danishロケールで "goddag verden!" としてマップできます。リソース バンドルは、必要なリソースの種類に応じて、テキスト ファイルまたは Java クラスのいずれかになります。
ASP.NET と.NET Frameworkでは、ユーザーのロケールの包括的な説明がカルチャ オブジェクトに含まれています。 カルチャ固有の書式設定は、日付/時刻、数値、テキスト情報クラスのカルチャ固有のインスタンスによって自動的に提供されます。 テキストやイメージなどのカルチャ固有のリソースを取得するために、ランタイムは Resource Manager を使用します。リソース ファイルを読み取り、現在のカルチャに基づいて適切なリソースを返します。
リソースは開発中に XML ファイルに保持されますが、運用環境で最適なパフォーマンスを得るための複数のサテライト アセンブリにコンパイルできます。 既定のカルチャはメイン アセンブリにコンパイルされ、カルチャごとに追加のサテライト アセンブリがあります。
トレースとインストルメンテーション
トレースでは、実行時のアプリケーションの実行に関する有益なメッセージが提供され、障害診断が容易になります。 一方、パフォーマンス カウンターを使用してアプリケーションのパフォーマンスを測定および監視するには、インストルメンテーションが重要です。
ストラットは、Log4J コンポーネントを介したログ記録と、複数のアプリケーション サーバーによって提供される機能を介した制限付きトレースを提供します。 多くの場合、これらの機能は実際のアプリケーション サーバーに依存し、システムによって大きく異なります。 J2EE と Struts はどちらも、パフォーマンス カウンター、ランタイム トレース、またはその他の組み込みインストルメンテーションを暗黙的に提供しません。 開発者は、サード パーティ製品を選択するか、トレースとインストルメンテーション用に独自のシステムを作成する必要があります。
トレース リスナーとスイッチ
ASP.NET.NET 基本クラス ライブラリを使用すると、トレース リスナーとスイッチの概念に基づく包括的なトレース機能が提供されます。 Trace クラスと Debug クラスには、トレース リスナーによって受信および処理されるトレースを生成するためのオーバーロードされたメソッドが多数用意されています。 ランタイムには、ファイル、イベント ログ、または IDE のデバッグ ウィンドウにトレース メッセージを書き込むさまざまな種類のリスナーが用意されています。 開発者は、独自のトレース リスナーを作成して、キュー、データベースなど、さまざまな宛先にトレース メッセージを書き込むことができます。 トレース スイッチを使用すると、トレース スイッチの値に基づいてトレースを有効、無効、またはフィルター処理できます。 既定では、フレームワークには 4 つのトレース レベル (エラー、警告、情報、詳細) が用意されていますが、独自のトレース スイッチ階層を作成できます。 トレース リスナーとトレース スイッチは、アプリケーションのweb.config ファイルを介して構成されます。 デバッグ ステートメントとトレース ステートメントを特定のビルドにコンパイルするかどうかは、コンパイラ スイッチによって制御されます。
アプリケーション レベルのトレース
ASP.NET のもう 1 つの重要なトレース機能は、構成ベースのアプリケーション レベルのトレースです。 web.config ファイルでこの機能を有効にするだけで、ASP.NET は大量の診断情報を収集し、要求されたページに追加します。 収集される情報には、実行タイミング、コントロール ツリー、セッションとアプリケーションの状態、Cookie、ヘッダー、フォーム、クエリ文字列、サーバー変数などが含まれます。
パフォーマンス カウンター
ASP.NET には、多数のパフォーマンス カウンターも用意されています。 これらは、要求、セッション、エラー、キャッシュなどについて、ASP.NET のランタイム パフォーマンスに関する詳細なメトリックを提供します。 これらの組み込みカウンターに加えて、独自のパフォーマンス カウンターを作成して、受信、承認、拒否された注文の数などのアプリケーション固有のメトリックを報告できます。
エラー診断
エラー診断側では、アプリケーション内の問題の原因を特定する方が簡単になりました。 開発者は、ブレークポイントを設定し、ページとバックエンド コンポーネントの両方をステップ実行できるだけでなく、エラーが発生すると、ASP.NET は完全なスタック トレースを含む詳細なエラー メッセージを生成します。 これにより、問題の原因を見つけるのに費やす時間と労力が大幅に削減されます。
フレームワーク パターン
Strstrs と ASP.NET 以前は、Java と Microsoft 開発者のどちらも、アプリケーションの複雑さに対処するためのガイドラインを持っていませんでした。 多くの大規模な J2EE および ASP アプリケーションは、この優れた例です。 アプリケーションの多数のレイヤー間の依存関係により、変更、更新、または拡張が困難になりました。 データベースの結果キャッシュを既存の J2EE または ASP アプリケーションに追加するには、アプリケーションの各ページを検索し、データ キャッシュを含むようにコードの関連するすべてのインスタンスを繰り返し変更する必要があります。
また、コードをページに組み込むことにより、同じアプリケーションで複数の市場 (クライアント サーバーや PDA など) をターゲットにすることが困難になりました。これは、コードを複製し、これらのプラットフォーム全体で大幅に再設計する必要があるためです。 多くの企業は、この問題に対処するための独自のフレームワークを開発し始めました。ただし、Strstrs と .NET が登場するまで、包括的なフレームワークは使用されませんでした。
このセクションでは、Mvc パターンを使用して、Strstrs と ASP.NET がアプリケーションの複雑さに対処する方法について説明し、各実装の固有の利点を特定します。
MVC パターン
Web のずっと前に、ソフトウェア アーキテクトはコンソール アプリケーションとまったく同じユーザー インターフェイスの問題に取り組んでいました。 この問題を解き分けることで、ソフトウェア アーキテクトは Model-View-Controller (MVC) パターンを定義することができました。 MVC は、Smalltalk-80 ユーザー インターフェイスを標準化するために使用された Smalltalk MVC フレームワークで最初に商用実装されました。
MVC パターンは、基本的にアプリケーションをモデル、ビュー、コントローラーの 3 つの部分に分けます。 MVC 定義では、モデルはアプリケーションで使用可能なすべてのアクションとビジネス ロジックをカプセル化し、View はアプリケーションのプレゼンテーション レイヤーを表し、コントローラーはイベントが発生したときに適切なアクションが実行されるようにするメカニズムを表します。
ユーザー インターフェイスの問題に対処するために、MVC パターンは、その後採用され、適合され、J2EE および .NET エンタープライズ アプリケーション プラットフォームに組み込まれています。 次の 2 つのセクションでは、Mvc パターンのStrstrs と ASP.NET 実装について説明します。
J2EE と ASP.NET の MVC
J2EE MVC: ストラット
支柱アーキテクチャは、基本的に フロントコントローラー と インターセプトフィルタ パターンの組み合わせから派生しています。 Struts フレームワークは、アプリケーション イベントを制御する 1 つのコントローラーを提供しますが、フィルターは受信イベントと送信イベントをキャッチして処理し、各 MVC コンポーネントが必要な情報を正確に受け取れるようにします。 たとえば、Struts Validator は、コントローラーが検証済みの要求のみを確実に受け取れるようにするフィルターです。
Struts フレームワークは Java アプリケーションのファサードとして機能し、アプリケーションのコードを MVC パターンで定義された Model、View、Controller コンポーネントに分割するフレームワークを提供します。 また、これらのレイヤー間の通信用のカスタム タグと、イベントとアクションを管理するための一元化されたコントローラーも提供します。 詳細については、「Struts MVC の実装」セクションを参照してください。
ASP.NET MVC: ページ コントローラー
ASP.NET は、ページ コントローラー パターンを使用して MVC を実装します。 完全なアプリケーション レベルの制御を可能にするStrstrs 実装とは対照的に、ページ コントローラー パターンは個々のページのレベルでコントローラーを適用します。 ASP.NET ランタイムは、ページ要求をインターセプトし、モデルで要求されたアクションを呼び出し、結果のページに使用する正しいビューを決定します。 インターセプトとディスパッチ ロジックは自動化され、開発者には表示されません。 ASP.NET は、各ページを 2 つの部分に分割します。さまざまなコントロールを含むビューと、ASP.NET コントローラーがページを処理する際に発生できるすべてのイベントのイベント ハンドラーを含む分離コード。 開発者は、実際の制御メカニズムと対話する必要はありません。モデルを接続してコンポーネントを表示するイベント ハンドラーを記述するだけです。 詳細については、「ASP.NET MVC 実装」セクションを参照してください。
非常に複雑で大規模なアプリケーションでは、通常、ページ間ナビゲーションとページ間ナビゲーションの柔軟性が高くなります。 この柔軟性を提供するために、ASP.NET コントローラーメカニズムは、ページ コントローラーを一元化するか、ASP.NET にフロント コントローラー パターンを実装することによって、2 つの異なる方法で改善できます。
ページ コントローラーの一元化
オブジェクト指向プログラミングに慣れていない開発者は、継承とページ コントローラーの機能を見落とす傾向があります。 アプリケーションが増えるにつれて、アプリケーションの複雑さの問題が発生する可能性があります。 ただし、この場合は必要ありません。 継承を使用すると、各ページは基本ページ クラスからコントローラーとビュー コンポーネントを継承できます。 継承を使用すると、一元化されたポイントから連鎖的な変更を行い、より複雑で複雑なコントローラー パターンを実装することなく、コードの複雑さを軽減できます。 ただし、大規模なアプリケーションをゼロから実装する場合は、独自のフロント コントローラーの実装を検討するか、ユーザー インターフェイス プロセス (UIP) を調査することをお勧めします。
ASP.NET でのフロント コントローラーの実装
ページ コントローラーの代替手段の 1 つは、カスタムHttpHandlerオブジェクトに基づいて単一のアプリケーション レベル コントローラーを作成することです。 はHttpHandler、ASP.NET ページが要求を受信する前に要求をインターセプトします。 コントローラーは、その後、支柱コントローラーと同様のアクションを実行できます。 同様の方法を使用して、インターセプト フィルターの形式で前処理と後処理を提供できます。 コントローラーとは異なり、フィルターは単に受信要求または送信応答を変更します。
.NET では、インターセプト フィルターを使用したフロント コントローラーの実装はかなり簡単です。 ( 「frontcontrollerdemo.msi」を参照してください)。実装のコントローラー部分は、通常、ハンドラーとコマンド プロセッサの 2 つの部分に分割されます。 Handler オブジェクトは、Web サーバーから要求を受信し、それらを処理し、Web.Config ファイルに格納されている XML パラメーターに基づいて適切なコマンドを選択します。 コマンド プロセッサは、要求を満たすために必要な特定のコマンドを実行します。 完了すると、適切なページを表示できるように、コマンドはメカニズムを介して転送されます。
ASP.NET でのフロント コントローラーとインターセプト フィルターの実装の詳細については、「 パターンとプラクティス 」Web サイトを参照してください。 Microsoft の Patterns and Practices (P&P) グループでは、アーキテクチャに基づく健全なソリューションを設計、構築、展開、運用する方法に関するガイダンスと推奨事項を提供しています。 P&P では、パターン、参照アーキテクチャ、構成要素、ライフサイクル プラクティスに関するガイダンスが提供されます。 さらに、P&P Web サイトでは、フロント コントローラーとインターセプト フィルター パターンなど、このペーパーで説明されているすべてのパターンについて包括的な説明と実装ガイダンスを提供します。
- フロント コントローラー パターン
- HTTP ハンドラーを使用した ASP.NET でのフロント コントローラー パターンの実装
- インターセプト フィルター パターン
- HTTP モジュールを使用した ASP.NET でのインターセプト フィルターの実装
フロント コントローラー パターンの実装は、次のバージョンの ASP.NET に含まれます (コード名 ASP.NET "Whidbey" は、Microsoft Visual Studio® .NET の今後のリリースのコード名の後に含まれます)。 ただし、タイミングに問題がある場合は、UIP アプリケーション ブロックの使用を検討してください。
ユーザー インターフェイス プロセス (UIP)
ユーザー インターフェイス プロセス (UIP) は、フロント コントローラー パターンとよく似ています。 [パターンとプラクティス] グループによって作成された UIP アプリケーション ブロックは、ページ コントローラー パターンの拡張機能です。 より堅牢なコントローラー メカニズムのフレームワークを提供し、非常に複雑なアプリケーション用のフロント コントローラーを構築する必要がなくなります。
UIP は、制御フローと状態管理をユーザー インターフェイスから別のレイヤーに抽象化します。これは、基本的に構成駆動型のステート マシンです。 UIP は、Windows、Web、PDA アプリケーションなど、任意の数のユーザー インターフェイスから利用できるように設計されています。 これにより、これらのさまざまな種類のアプリケーションのフロントエンド制御フローと状態管理の汎用コードを記述できます。 その結果、ターゲット クライアント間で簡単に切り替えることができる、より汎用性の高いアプリケーションになります。 UIP の主要な要素 (灰色) を次の図 2 に示します。
.gif "Aa478961.aspnet-aspnet-j2ee-struts-02(en-us,MSDN.10).gif")
図 2. ユーザー インターフェイス プロセスの主要な要素 (灰色)
UIP アプリケーション ブロックには、提供されるコードについて学習するのに役立つ完全なソース コード、Starter Kit サンプル、および包括的なドキュメントが付属しています。 パターンとプラクティス Web サイトからダウンロードできます。
楽しみ
Web の進化が続き、アダプティブ J2EE および .NET フレームワークがテストに追加されます。 では、未来はストラットと ASP.NET のために何を保持しているのでしょうか? このセクションでは、J2EE と .NET のフロントに関する新しいテクノロジの一部について簡単に説明します。
ストラットとJ2EEの未来
Strstrsフレームワークは非常に成熟しており、その主要なコンポーネントの多くはメインJ2EEフレームワークに吸収されています。 将来のストラットの成長は、タイルや JavaServer Faces などの新しい J2EE システムを利用する可能性があります。 ただし、フレームワーク自体が重要な方法で変更される可能性は低いです。
プラグインと IDE の統合をサポート
現在、Strstrs フレームワークの拡張と開発環境への統合の両方について、いくつかの取り組みが進行中です。 現在、いくつかのベータ プラグインは、Strstrs フレームワークで使用されるイベント コードを自動生成するために使用できます。 これらのプラグインは、ストラット開発者の生産性を大幅に向上させる必要があります。 さらに、いくつかの IDE ベンダーは、開発環境の内部に中にStrrators フレームワークを組み込む IDE プラグインを開発または取り組んでいます。 これらのプラグインは、効率的な方法で開発環境から直接ストラットを使用するための統合システムを効果的に提供します。
支柱の拡張機能とプラグインの一覧は、 スラット アプリケーション の Web サイトにあります。
JSP とタイル
タイルは、小さなフラグメントからページを構築するのに役立ちます。 タイルは、JavaServer Pages (JSP) 仕様によって提供される "インクルード" 機能に基づいて構築され、コンポーネント パーツからプレゼンテーション ページをアセンブルするためのフル機能の堅牢なフレームワークを提供します。 各パーツ ("タイル") は、アプリケーション全体で必要な頻度で再利用できます。 これにより、維持する必要があるマークアップの量が減り、Web サイトの外観を簡単に変更できるようになります。
フレームワークでは、XML 構成ファイルを使用してこれらのタイルを整理します。 このフレームワークを使用すると、タイルを再利用できるだけでなく、タイルを整理するレイアウトも再利用できます。
基本的に、タイルはカスタム タグとコントロール ASP.NET よく似ていますが、ASP.NET タグは分離コードで操作できるという意味でより強力です。
タイルの詳細については、以下を参照してください。
JavaServer Faces
JavaServer Faces テクノロジの目的は、JSP アプリケーションのユーザー インターフェイスの構築を簡素化することです。 さまざまなスキル レベルの開発者は、再利用可能な UI コンポーネントをページに組み立て、これらのコンポーネントをアプリケーション データ ソースに接続し、クライアントによって生成されたイベントをサーバー側のイベント ハンドラーに結び付けることで、アプリケーションをすばやく簡単に構築できます。 JavaServer Faces テクノロジを使用すると、これらのアプリケーションはサーバー上のユーザー インターフェイスを管理する複雑さをすべて処理し、アプリケーション開発者がアプリケーション コードに集中できるようにします。
JavaServer Faces テクノロジには、次のものが含まれます。
- UI コンポーネントを表し、その状態を管理し、イベントと入力の検証を処理し、ページ ナビゲーションを定義し、国際化とアクセシビリティをサポートするための一連の API
- JSP ページ内で JavaServer Faces インターフェイスを表す JavaServer Pages (JSP) カスタム タグ ライブラリ
これは、ASP.NET が提供する機能に似ています。
ASP.NET の未来と.NET Framework
Microsoft は .NET に強いコミットメントを持っています。 これは、長期的な戦略の基礎です。 .NET Frameworkはオペレーティング システムに組み込まれており、次のバージョンの Windows のコードネーム Longhorn の一部としてリリースされます。 また、Microsoft は製品ラインを .NET に移行し、これらすべての製品の開発環境として Visual Studio .NET を利用しています。
ASP.NET は.NET の重要なコンポーネントです。 Microsoft は、次のような次のリリースの大幅な機能強化と新機能に取り組んでいます。
- メンバーシップとロール管理サービスの組み込みサポート
- ユーザー設定を設定および取得するための新しいパーソナル化サービス
- 新しいサイト ナビゲーション システム
- 45 を超える新しいサーバー コントロール
- モバイル デバイスへの自動レンダリング
- グラフィカル構成ファイルの編集
- アプリケーション管理の簡素化
さらに、Microsoft では、フロント コントローラー パターンを含むように MVC 実装を変更する予定です。 次のバージョンの ASP.NET(codenamed Whidbey)の詳細については、 ASP.NET Web ページを参照してください。
サード パーティ製の開発
多くのサード パーティは、.NET の機能を拡張するためのツールを開発しています。 最も顕著なのは、Avanade の製品である ACA .NET です。これは、フレームワークと、開発プロセスを加速するための事前構成済みの Web サービスとアプリケーション コンポーネントのセットの両方を提供することで、Visual Studio .NET を補完します。
ストラットおよび J2EE アプリケーションを ASP.NET に移行する
C# と ASP.NET に移行する、Strstrs ベースのアプリケーションがある場合は、Java 言語変換アシスタント (JLCA) と JSP から移行ガイドに記載されている資料を利用 ASP.NET。 このガイドは、MSDN® ライブラリで入手でき、スラット ベースの Web サイトを C# および ASP.NET Web サイトに完全に変換する方法について説明します。 フロント コントローラーの サンプル コード (XML 参照と を CommandFactory含む) が見つかるだけでなく、JLCA を使用して既存の中柱アクションをほぼ直接変換する方法を確認できます。
Struts アプリケーションを .NET に変換する際の主な難しさは、コントローラー機能の置き換えです。 前述のように、ASP.NET には の概念 ActionServletに直接相当するものはありません。 したがって、あなたのストラットクラスの一対一変換を行うには、フロントコントローラパターンを活用し、ストラット ActionServletの機能を実行する をHttpHandler記述する必要があります。 このコンポーネントを開発 (または JSP から移行ガイド ASP.NET ダウンロード) したら、JLCA を使用して、残りの Action クラスを同等の C# クラスに直接移行できます。 プロセス全体はかなりシンプルで、移行ガイドに記載されています。 変換の結果は、ASP.NET のストラットのようなアプリケーションになります。ただし、java 中心のソリューションは引き続き ASP.NET で実行されます。 移行の次のフェーズでは、ASP.NET 機能とベスト プラクティスの活用を開始します。 たとえば、Struts 検証コードを ASP.NET 検証コントロールに置き換える必要があります。 また、特定のアクションやビューを書き換えて、ASP.NET コントロール (たとえば、 DataGrid など) と.NET Framework機能を利用することもできます。
概要と結論
Web アプリケーションが成熟するにつれて、堅牢で完全に統合された開発システムの必要性が高まります。 J2EEと.NET Frameworkの両方がそのようなシステムを提供しています。 各フレームワークは、オペレーティング システムから始まり、ランタイム、言語、API レイヤー間を移動するスタック上に構築されます。 各フレームワークには、アプリケーション開発のためのさまざまな機能と利点があります。 このペーパーで説明したように、これらのスタックにパターンを追加することで、高品質のアプリケーションを提供する能力がさらに向上します。
.NET Framework スタックには、対応する J2EE に比べていくつかの大きな利点があります。 .NET は Windows オペレーティング システムと完全に統合されており、OS はアプリケーション サーバーを提供するため、.NET アプリケーションでは、ほとんどの J2EE システムよりもはるかに緊密な統合、豊富な機能コンテンツ、高速なパフォーマンスを利用できます。 開発レベルでは、ASP.NET を使用した開発には JSP よりも少ないコードが含まれます。 さらに、検証、キャッシュ、トレースなどの多くの機能が ASP.NET に組み込まれていますが、JSP にはサードパーティ製のコンポーネントが必要です。
長期的には、ASP.NET、.NET Framework、およびユーザー インターフェイス プロセスは、Web アプリケーションを開発、展開、サポートするための完全で強力なフレームワークを提供します。 Microsoft は Web 開発エクスペリエンスの向上に取り組んでいるため、ASP.NET と.NET Frameworkは、近い将来のエンタープライズ開発のニーズを引き続き満たします。
リファレンス
このホワイト ペーパーの作成者は、さまざまな資料文献から情報を得た。 主な参照の一部を次に示します。
ASP.NET ライフサイクル
- ASP.NET 処理パイプラインの詳細については、MSDN マガジンの記事「ASP.NET の HTTP パイプラインを使用して要求処理、フィルター処理、コンテンツ リダイレクトを安全に実装する」を参照してください。
- ASP.NET ページ オブジェクト モデル
フレームワークの並列
Visual Basic と Visual C# の概念: Web Forms状態管理の概要
Java アプリケーション
- CodeNotes for J2EE - Random House Publishing Inc., 2001, New York, New York
- CodeNotes for Java — Random House Publishing Inc., 2001, ニューヨーク, ニューヨーク
ASP.NET 検証コントロール: Web Forms検証
Struts
- 支柱の ホーム ページ
- ジャカルタのストラットをマスター — ジェームズの親善。 2002年、インディアナポリス、インディアナ州
Microsoft のパターンとプラクティス
- Microsoft .NET を使用したエンタープライズ ソリューション パターン
- FrontController サンプル コードは、ASP.NET サンプル コード ページにあります
- JSP から ASP.NET 移行ガイド
ユーザー インターフェイス プロセス
- .NET 用 Microsoft アプリケーション ブロック
- .NET Rocks - 2003 年 4 月 28 日、Microsoft コンサルティング サービス (MCS) のシニア コンサルタントである Michael Stuart に、次世代の Microsoft アプリケーション ブロックまたは BlueBricks についてインタビューしました。
著者について
M. Keith Mortensen は、 インフュージョン開発のシニア ソフトウェア開発者兼コンサルタントです。 Rob McGovern は 、注入開発のシニア プロジェクト マネージャーであり、 CodeNotes for Java、CodeNotes forJ2EE、CodeNotesfor ASP.NET、 CodeNotes for J#、 CodeNotes for Web Services 、 CodeNotes for Oracle 9i の作成者です。 Charles Liptaak は、Microsoft のプラットフォーム戦略とパートナー グループのパートナー ソリューション アーキテクトです。
著者たちは、Brian Goldfarb、Steve Ellis、Brent Williams、Greg Brill、Cortez La Palme、Dale Baik の助けを借りて認めたいと考えます。
補遺
フォーム認証の拡張
フォーム認証は によって FormsAuthenticationModule実行されます。これにより、受信要求が に渡される前にHttpHandlerインターセプトされます (ASP.NET モジュールとハンドラーの詳細については、「ASP.NET MVC 実装」セクションを参照してください)。
認証モジュールは イベントをOnAuthentication発生させます。これにより、開発者は何らかの ID ストア (データベースなど) に対して認証を実行し、認証チケットを作成できます。 後続の要求では、このチケットの有効性 (同じイベント ハンドラー内) を調べ、チケットの有効期限が切れた場合はログイン ページにリダイレクトします。 要求のヘッダーで送信された Cookie に基づいて、ASP.NET はユーザーの ID を再取得し、要求間の認証チケットの作成を処理します。
ロール ベース セキュリティ
URL 承認のユーザーとロールは、認証時にランタイムによって現在のスレッドにアタッチされる ID オブジェクトとプリンシパル オブジェクトにマップされます。 Windows 認証の場合、これらのオブジェクトは Windows ユーザーとグループに直接マップされます。
URL 承認によって提供されるロールベースのセキュリティに加えて、ASP.NET ではカスタムのRole-Based セキュリティがサポートされます。 Role-Based Security では、適切なロールを持つ独自の 'Principal' オブジェクトを作成し、スレッド上の既定のオブジェクトを独自のオブジェクトに置き換えることができます。 通常は、データ ストアからカスタム ロールをOnAuthentication取得した後、イベントでこの種類のセキュリティを適用します。
Model-View コントローラー (MVC) パターン
MVC パターンは、基本的に、アプリケーションのユーザー エクスペリエンスを 3 つのコンポーネント (モデル、ビュー、コントローラー) に並べ替える方法です。 これらの用語は、多くの場合、開発の世界ではオーバーロードされます。 明確にするために、MVC フレームワークを参照する場合、アプリケーションのセグメント化方法は次のようになります。
- モデルはビジネス ロジックへのゲートウェイであり、機能の観点からユーザー エクスペリエンスを管理します。
- [表示] はプレゼンテーション レイヤーであり、ユーザーに使用可能なアクションと、それらを使用するために必要な情報を提供します。
- コントローラーは、モデルとビューの間のブリッジであり、ユーザーからの要求を解釈し、必要に応じてモデルやビューを変更するようにコマンドを実行します。
一般的なデータ フローを図 3 に示します。
.gif "Aa478961.aspnet-aspnet-j2ee-struts-03(en-us,MSDN.10).gif")
図 3: Web コンテキストでのModel-View コントローラー (MVC) パラダイム
イベント (ページ要求など) が発生すると、MVC パラダイムによって次のように処理されます。
- イベントはコントローラーによってインターセプトされます。
- Controller はイベントを評価し、Model 内の適切なハンドラーにマップします。
- モデルによってアクションまたは状態の変更が実行され、結果がコントローラーに返されます。
- コントローラーは、表示する適切なビューを決定し、アプリケーションがそのビューに転送します。
- ビューは、読み込み時に、データ インターフェイスを介してモデルからデータを取得できますが、アクション (データベース呼び出しなど) を直接実行することはできません。
- ビューがユーザーに表示されます。
MVC パターンによって作成されたコンポーネントの分離は、各コンポーネントが論理的にグループ化されたタスクの個別のセットを担当するため、UI の依存関係を排除するのに役立ちます。
ストラット MVC の実装
Strstrs プロジェクトの唯一の目的は、開発者に拡張可能なアプリケーションを構築するための柔軟なフレームワークを提供するために、MVC パターンを J2EE プラットフォームに導入することでした。 1年間の開発の後、ストラットはJ2EEの世界でMVCの空隙を埋めるために生まれました。 ストラット アーキテクチャは、Java アプリケーションのラッパーとして機能し、そのコードを MVC パターンで定義されたモデル、ビュー、コントローラーに分割します。
MVC 分析
ストラットは MVC を実装して、1 つのコントローラーがアプリケーション イベントを制御できるようにします。 これらの受信イベントと送信イベントは、特定の用途に合わせて受信データを変更および成形するフィルターによってインターセプトできます。 これは、MVC パターンのフィルターバリエーションをインターセプトするフロント コントローラーとよく似ています。
モデル
モデルはかなりオープンエンドであり、さまざまなサードパーティの実装を可能にします。 最も一般的な実装の 1 つは、エンタープライズ JavaBeans (EJB) を活用して、データの永続化、トランザクションサポート、標準フレームワークを実現します。 その他のモデル実装には、データ アクセス オブジェクト (DAO)、Plain Old Java Objects (POJO)、およびその他の形式のロジックカプセル化とデータ永続化 (オブジェクト リレーショナル マッピング、ORM ツールなど) があります。 これらのモデル実装はすべて、Java で開発するか、Java ベースのインターフェイスを持っている必要があります。
表示
View コンポーネントは通常、 JavaServer Pages (JSP) として実装されます。 JSP は、主に HTML およびサーブレット上で拡張されるマークアップ言語です。 JSP マークアップ言語では、カスタム タグ ライブラリの開発がサポートされています。 カスタム タグ ライブラリは、JSP で使用するとバックエンド クラスにアクセスし、特定の関数を実行する HTML に似たタグを表します。 カスタム タグ ライブラリは、JSP を拡張し、ビューとモデルの間のシームレスな相互作用を容易にするために、支柱で使用されます。
コントローラー
既定のコントローラーは、すべてのクライアント要求を処理し、要求ごとに適切なアクションを実行する単一のサーブレット インスタンスに一元化されます。 Struts フレームワークは、コントローラーの既定の実装を提供します。 開発者の主なタスクは、イベントの結果として発生するアクションを登録して実装することです。 アクションは、拡張する必要がある共通基本クラスとして定義され、すべてのイベントと応答が XML 構成ファイルに登録されます。 たとえば、要求の受信 URI を適切なアクション クラスに適切にマップし、アクション クラスを実装して受信要求を処理できるように、アクション マッピングを入力する必要があります。 また、アクションの転送条件も登録して、コントローラーがアクションの完了時に必要なビューを認識できるようにする必要があります。
ページ読み込み処理シーケンスの支柱
一般的な要求では、次のマルチステージ プロセスが実行されます。
.gif "Aa478961.aspnet-aspnet-j2ee-struts-04(en-us,MSDN.10).gif")
図 4: 支柱ページ処理シーケンス
- ブラウザー要求は、サーバーごとに 1 つの物理インスタンスを持つ Action サーブレット クラスに送信され、処理されます。
- アクションサーブレットは、要求プロセッサを呼び出して、要求オブジェクトと応答オブジェクトを準備し、アクションマッピングなどを決定します。
- 要求プロセッサは、対応する Action Form Bean を作成 (または再利用) し、html フォームの入力フィールドを設定し、フォーム検証を呼び出します (必要な場合)。
- 構成ファイル内のアクション マッピングを使用して、要求プロセッサは適切なアクション クラスに制御を渡します。 アクション クラスのStrstrs フレームワーク プール インスタンス。したがって、アクションが既に要求されている場合は、すべての要求で作成されるのではなく、インスタンス プールから取得されます。 ただし、マルチスレッドを使用しない場合、複数のユーザーが同じアクションにアクセスすると、重大な競合が発生する可能性があります。
- Action クラスはビジネス ロジック Bean を呼び出し、アクション フォーム (またはその一部) をモデルに渡します。 モデルは、EJB ベースであるか、プレーンな Java オブジェクトで構成される場合があります。
- アクションの実行が完了すると、要求のターゲットを決定する Action Forward オブジェクトとして返されます。
- 制御が最終的に要求プロセッサに返され、要求が適切なターゲットに転送されます。
- JSP ページでは、一連のタグ ライブラリを介してモデルからデータを取得できます。
このプロセスは一見複雑に見えるかもしれませんが、これらの手順のほとんどは、ストラットフレームワークのおかげで自動的に行われます。 開発者は、主にマッピングの設定とアクション クラスの記述に関心があります。
ASP.NET MVC の実装
生産性を向上させ、開発者が信頼性と拡張性の高いソリューションを構築できるように、ASP.NET は既定のすぐに使用できる MVC フレームワークを提供します。 ASP.NET の MVC 実装には、ページごとに 1 つのコントローラーがあり、ページ コントローラー パターンと呼ばれます。
ASP.NET のページ コントローラー パターンは、イベントをキャプチャし、クライアントから適切なハンドラーに中継する方法で実装され、開発者には見えないままで自動です。 開発者は、より複雑なハンドラーを開発するのではなく、イベントに対処するために必要なアクションのみを実装することに関心を持つことができます。
MVC 分析
各 ASP.NET ページは、さまざまなコントロールを含むビューと、コントローラーとして機能する分離コードの 2 つの部分に分かれています。 分離コードには、イベントの生成時にコントローラーが実行できるすべてのアクションの関数が含まれています。 これらの関数は、必要に応じてモデルと結果のビューに関連付けることができます。
モデル
モデルは、単純なオブジェクト (C# クラスなど) またはマネージド コンポーネント (Enterprise Services、COM+ など) で構成できます。 さらに、トランザクション サポート (ADO.NET と COM+)、データ永続化 (ADO.NET)、キャッシュなど、さまざまなサービスとシステムにフレームワークからネイティブにアクセスできます。 ASP.NET モデルは、C#、VB.NET、J#、Perl など、.NET Frameworkでサポートされている多くの言語のいずれかを使用して実装できる点で、ストラット モデルとは異なります。
表示
.NET Framework ベースのアプリケーションのビューは、ASP.NET と任意の .NET 言語を使用して実装されます。 ASP.NET は、(スクリプトではなく) コンパイルされた言語のサポートを提供し、ブラウザー固有の出力を自動的に生成することで ASP を拡張します。 ASP.NET には、コントローラーとビューの間のシームレスな対話のための広範でカスタマイズ可能なコントロール ライブラリが用意されています。 ASP.NET では、"ドラッグ アンド ドロップ" 開発インターフェイス (Visual Studio .NET または Web マトリックス)、改良されたコントロール、ブラウザーに依存する HTML の自動生成など、JSP よりもいくつかの利点があります。 つまり、ASP.NET のコントロールによってブラウザーの種類が自動的に決定され、ブラウザー固有のコードが生成されます。 J2EE フレームワークには同様の機能はありません。ただし、一部の Java ベンダーでは、同様の機能を備えたタグ ライブラリを開発しています。
コントローラー
ページ コントローラーのアプローチは、コントローラーがページに直接組み込まれているので、開発者は、Strstris よりもはるかに簡単に実装できます。 開発者は、アプリケーション全体のイベントをマッピングするのではなく、1 つのページのイベントのみを処理する必要があります。 これは、ビューとコントローラーで継承を利用できるため、非常に強力な実装になる可能性があります。 ただし、この実装が適切に設計されていない場合、アプリケーションは非常に複雑になり、保守が困難になり、前に説明した構成の問題の一部が再導入される可能性があります。 予防策については、「ページ コントローラーの一元化」セクションと、「フロント コントローラー」と「ユーザー インターフェイス プロセス」セクションの代替方法について説明します。
ASP.NET ページ処理 - 内部の外観
ASP.NET ページ処理の多くは開発者には隠されています。しかし。 これはモジュール式であり、開発者が使用する必要がある場合に使用できます (セキュリティなど)。 このセクションでは、ASP.NET ページが処理されるときに発生するバックグラウンド アクションについて説明します。
.gif "Aa478961.aspnet-aspnet-j2ee-struts-05(en-us,MSDN.10).gif")
図 5: ページ処理シーケンスの ASP.NET
IIS は要求を受信すると、aspnet_wp.exeと呼ばれる ASP.NET ワーカー プロセスに転送します。 現時点では、マシンごとにワーカー プロセスは 1 つだけですが、ASP.NET バージョン 2.0 で変更されています。 同じコンピューター上で複数のワーカー プロセスを実行できるため、同じ物理ハードウェアで実行されている Web サイトを完全に分離できます。
ワーカー プロセスは要求を受け取ると、 のHttpRuntimeインスタンスを使用して処理します。 ではHttpRuntime、受信要求を調べて、それがどのアプリケーション用であるかを調べ、オブジェクト ファクトリを使用して の HttpApplicationインスタンスを作成します。 HttpApplicationには のコレクション HttpModulesが含まれており、受信要求を検査し、認証や状態管理などの一般的なタスクを実行します。 がタスクをHttpModules実行すると、 は別のHttpApplicationオブジェクト ファクトリを使用して のインスタンスを作成します HttpHandler。 パフォーマンスHttpApplicationを向上させるために、およびHttpHandlerオブジェクトがプールされます。
これは、実際の ASP.NET ページが入ってくるポイントです。 既定では、すべてのページで クラスがSystem.Web.UI.Page拡張され、 インターフェイスがIHttpHandler実装されます。 ページの読み込みが開始されると、さまざまなイベントが発生し、分離コードの実行が開始されます。 分離コードから、Business ファサードまたはビジネス ロジック レイヤーを呼び出して、住所の変更、新しい連絡先名の追加など、さまざまなビジネス機能を実行できます。