デザインパターンはより良いJ2EEアプリになります
J2EE（Java 2 Platform、Enterprise Edition）は、その開始以来、Javaでのエンタープライズアプリケーションの構築を簡素化してきました。ただし、J2EEがより広く採用されるようになると、開発者は、アプリケーション構築を簡素化および標準化する定義済みのアプローチの必要性を認識しています。アプリケーションのアーキテクチャ層を標準化することで、その目標の達成を開始できます。
アーキテクチャ層は通常、ビジネスロジックとは無関係にアプリケーションの技術的な複雑さをカプセル化し、それによってビジネス機能と基盤となる技術インフラストラクチャの間の疎結合を提供します。この記事では、J2EEプロジェクトのアプリケーションアーキテクチャを構築するための新しい方法について説明します。これは、優れたアーキテクチャが要求する標準化とシンプルさを提供するためにデザインパターンを採用する方法です。
アプリケーションアーキテクチャとJ2EE
J2EEは優れたインフラストラクチャテクノロジーです。これは、データベース通信やアプリケーション配布など、テクノロジースタックの下位レベルのタスクに統一された標準を提供します。ただし、J2EEは、開発者が成功するアプリケーションを構築するようには導きません。 J2EEの作成者は、テクノロジースタックを見下ろして、「これらのAPIをどのように標準化できるか」と疑問に思いました。彼らはアプリケーション開発者を見上げて、「開発者にビジネスアプリケーションに集中するために必要なビルディングブロックをどのように与えることができるか」と尋ねるべきでした。
新しいJ2EEプロジェクトを開始するとき、一部のチームメンバーは、「J2EE自体がアーキテクチャである場合、なぜもっと必要なのか」とよく尋ねます。多くの開発者は、J2EEの初期にはその誤解を抱いていましたが、経験豊富なJ2EE開発者は、J2EEが高品質のアプリケーションを一貫して提供するために必要なアプリケーションアーキテクチャを提供できないことを理解しています。これらの開発者は、多くの場合、そのギャップを埋めるためにデザインパターンを使用します。
デザインパターン
プログラミングでは、デザインパターンを使用すると、すべての人に役立つ問題と解決策を共有することで、開発者コミュニティの集合的な経験を活用できます。デザインパターンは、問題の定義とコンテキスト、考えられる解決策、および解決策の結果をキャプチャする必要があります。
J2EEアプリケーションアーキテクチャの目的上、デザインパターンは、一般的なソフトウェア開発パターンと特定のJ2EEの課題を特定するパターンの2つのカテゴリに分類されます。J2EE固有のデザインパターンは、堅固なアプリケーションアーキテクチャが解決する必要のある既知の問題の最小限のセットを識別します。前者のグループ、つまりJ2EEに固有ではないソフトウェア開発パターンのグループは、問題を特定するためではなく、アーキテクチャ構築をガイドするために、同様に強力であることが証明されています。
各領域をさらに詳しく調べてみましょう。
J2EEデザインパターン
J2EEのデザインパターンは、JavaコミュニティがJ2EEの経験を積むにつれて、過去数年にわたって進化してきました。これらのデザインパターンは、J2EEで指定されたさまざまなテクノロジを使用するときに発生する可能性のある問題を特定し、開発者がアプリケーションアーキテクチャの要件を構築するのに役立ちます。たとえば、人気のあるフロントコントローラーのデザインパターンは、構造化されていないサーブレットコードを、洗練されたGUI（グラフィカルユーザーインターフェイス）開発を彷彿とさせるコントローラーに変換します。
J2EEデザインパターンは、J2EEプロジェクトで発生する可能性が最も高いドメインの問題を特定します。実際、問題がまれである場合、デザインパターンはそれらに対応するように進化していなかったでしょう。そのことを念頭に置いて、アーキテクチャ内の各ドメインの問題に対処することでメリットが得られます。それらすべてを解決するには、アーキテクチャの完全性を検証するためのチェックリストを作成します。このプロセスは、次に説明するソフトウェア開発デザインパターンのプロセスとは対照的です。これらのパターンは、適切な場合にのみ適用する必要があるためです。
では、J2EEデザインパターンはどこにありますか？Sun Microsystemsは、多くのJ2EEパターンを含む2冊の本を提供しています。
- J2EE BluePrintGroupのJava2プラットフォーム（Enterprise Edition）を使用したエンタープライズアプリケーションの設計、 Nicholas Kassem etal。（Addison-Wesley、2000; ISBN：0201702770）
- Sun Professional Services GroupのコアJ2EEパターン：ベストプラクティスと設計戦略、 Deepak Alur、John Crupi、およびDan Malks（Prentice Hall、2001; ISBN：0130648841）
（両方の本へのリンクについては、「参考文献」を参照してください。）
Sunのリソース以外にも、さまざまなJava業界の雑誌やWebサイト（JavaWorldなど）や多数の書籍など、J2EEデザインパターン情報が提供されています。（JavaWorldのデザインパターントピックインデックスページを含む、これらのサイトのいくつかへのリンクについては、リソースを参照してください。）
ソフトウェア開発デザインパターン
また、一般的なオブジェクト指向（OO）デザインパターンとJava固有のデザインパターンに分けられるソフトウェア開発デザインパターンにも注意してください。たとえば、ファクトリパターンは、オブジェクトの作成をカプセル化して再利用を可能にし、システムの変化する要件を満たすための強力なオブジェクト指向設計パターンを表します。彼らの側では、Java言語のデザインパターンがJava言語の詳細を説明しています。一部はJavaに固有であり、通常は非公式です（たとえば、例外やプリミティブ）。その他は、Javaに適用するために改良されたOOパターンです。四つの本の有名なギャングのデザインパターンによってエリックガンマらは、すべてのプログラマに役立つ数多くの一般的なソフトウェア開発のパターンを詳細に説明します。
これらのパターンがJ2EE固有ではないという理由だけで、これらのパターンを却下しないでください。それどころか、そのようなパターンは、J2EEデザインパターンと同じくらい強力であることが証明できます。理由は次のとおりです。
- J2EEデザインパターンは新しく進化していますが（J2EEは新しく進化しているため）、他のパターンは、業界がそれらをレビューおよび改良するためのより多くの時間を持っているため、時代の恩恵を受けています。
- これらは、J2EEデザインパターンの基礎となることがよくあります。
- これらは、J2EE固有のソリューションを実装するための基盤を構築します。この基盤を正しく構築すると、アーキテクチャ全体の堅牢性と拡張性に大きく影響します。正しく構築されていない場合、基盤は、解決するJ2EE問題の数に関係なく、アーキテクチャの有用性を最小限に抑えます。
J2EEパターンの場合のように、アーキテクチャに必要なソフトウェア開発パターンをカバーするチェックリストを作成しないでください。代わりに、プロジェクトの特定の課題に基づいて、必要に応じてそのようなパターンを採用してください。多くの開発者は、より多くのパターンを使用すると、またはすべてのパターンを使用すると、製品が改善されると誤って信じています。ただし、そうではありません。使用するパターンとそれらを一緒に使用する方法を決定するときは、裁量と精巧さを使用してください。
デザインパターン：コードはどこにありますか？
デザインパターンには、使用する正確な実装やソースコードが付属していないことに注意してください。デザインパターンの提供範囲は、まばらなテキストの説明から豊富なドキュメント、場合によってはサンプルコードまで多岐にわたります。課題は、パターンの強力なアイデアを適用することです。これらのアイデアは、それらが使用される環境に適用する必要があります。環境は正しい実装を定義します。
例えとして、家の土台を構築するためのデザインパターンを考えてみましょう。設計パターンは、基礎を構築するための問題、コンテキスト、および可能な解決策を識別します。これらの情報は、現場の建設作業員にとって非常に価値があります。ただし、労働者は依然として基盤を構築する必要があります。その建設作業員は、（ソフトウェア開発者に実装が与えられるのと同様に）基盤が与えられることでより多くの利益を得るのではないでしょうか？たぶん、この土台は、家を建てることができるコンクリートのスラブにすぎないでしょう。問題：基礎は家自体と家が住む土地と統合しなければなりません。このような事前に構築された基礎は、考えられるすべての家の間取り図（長方形、正方形、およびその他の奇妙な形状）と考えられるすべての風景（丘の上、森の真ん中でなど）？
ソフトウェアの世界に戻ると、構築済みのデザインパターンを使用する可能性は、次の2つの要因にかかっています。
- 個々のデザインパターンではなく、実装がソリューションを表しています。このソリューションには、複数のデザインパターンを組み込むことができ、そうすることで、個々のデザインパターンがどのように連携するかがわかります。
- ソリューションは適応可能である必要があります。これは、構築済みの基礎の例えからの最後の質問に答えます。基礎は、地形と平面図に適応できる必要があります。ご想像のとおり、標準的な基礎とは対照的に、適応可能な基礎を構築するには、非常に熟練した職人が必要です。
一般的なデザインパターン
次の表に、J2EEソースとより広範なOOパターンの両方からのいくつかの一般的なデザインパターンを示します。
一般的なデザインパターン
|
2つのJ2EEデザインパターンの例を見てみましょう。セッションファサードパターンと値オブジェクトパターンです。どちらも、アプリケーション開発作業に一般的に適用されるソフトウェア開発設計パターンとは対照的に、J2EE設計パターンがJ2EE環境に固有の問題にどのように焦点を合わせているかを示しています。
例：セッションファサードJ2EEパターン
セッションファサードパターンは、Enterprise JavaBeans（EJB）の経験から発展しました。新しく導入されたエンティティEJB（データベースと通信する）上に構築されたシステムは、クロールが遅くなりました。パフォーマンステストにより、エンティティEJBとの通信時に行われた複数のネットワーク呼び出しに起因する問題が明らかになりました。これにより、ネットワーク接続の確立、送信と受信の両方のデータのシリアル化、およびその他の影響のためのオーバーヘッドが追加されました。
これに応じて、Session Facadeパターンは、これらの複数のネットワークヒットを単一の呼び出しに集中化することでパフォーマンスを向上させました。Session Facadeは、ステートレスセッションEJBを使用して、クライアント呼び出しと必要なエンティティEJBの相互作用を仲介します。Fast Lane Readerやデータアクセスオブジェクトのパターンなど、データベースアクセスのパフォーマンスを向上させるためのパターンがさらに存在します。
例：値オブジェクトJ2EEパターン
値オブジェクトJ2EEパターンは、ネットワーク上でEJBを使用するシステムのパフォーマンスを向上させることも目的としています。前の例のオーバーヘッドを誘発するネットワーク呼び出しは、個々のデータフィールドを取得します。たとえば、あなたが持っていることPersonのようなメソッドを持つエンティティEJBをgetFirstName()、getMiddleName()とgetLastName()。値オブジェクトデザインパターンを使用するとgetPersonValueObject()、データを一度に返すなど、エンティティEJBのメソッドを使用して、このような複数のネットワーク呼び出しを1つの呼び出しに減らすことができます。その値オブジェクトには、エンティティEJBが表すデータが含まれており、ネットワーク呼び出しのオーバーヘッドを発生させることなく、必要に応じてアクセスできます。
例：フライ級OOパターン
広く適用可能なオブジェクト指向設計パターンの例として、オブジェクトの再利用を通じてアプリケーションのパフォーマンスを向上させるFlyweightパターンを検討してください。OOソフトウェアは、オブジェクトを作成および破棄するときに、オーバーヘッド（CPUサイクルの浪費、ガベージコレクション、およびメモリ割り当て）を生成します。システムがこれらのオブジェクトを再利用できれば、そのオーバーヘッドを回避できます。ただし、オブジェクトには、オブジェクトの現在のユーザーに固有の情報（状態と呼ばれる）が含まれているため、オブジェクトは再利用できないことがよくあります。Flyweightパターンは、オブジェクトの残りの部分を再利用できるように、その状態を別の場所に移動するためのアプローチを提供します。
それらをすべてまとめる：永続性の例
基本を理解したので、開発プラクティスにデザインパターンを適用し始めることができます。しかし、実際にはどのようにパターンを使用しますか？解決策を必要とするドメインまたは技術的な問題を特定することから始めます。永続性（古くからのオブジェクトとリレーショナルデータベースの不一致を解決する）は、ほとんどのエンタープライズアプリケーションの良い例です。アプリケーションアーキテクチャの永続層を設計および構築するために必要な手順を見てみましょう。
従来のオブジェクト指向アーキテクチャと設計アプローチに従って、永続性のニーズを説明するユースケースを作成します。考えられる使用例は次のとおりです。
- オブジェクトの永続性は、開発者の観点から透過的である必要があります。
- 永続性メカニズム（エンティティEJB、データアクセスオブジェクトなど）は、アーキテクチャレベルで構成可能である必要があります。
- 私たちのアーキテクチャはJ2EEテクノロジーを利用する必要がありますが、J2EEの依存関係をカプセル化します。アプリケーション全体のオーバーホールを必要とせずに、J2EEアプリケーションサーバーベンダー、J2EEバージョンを変更したり、J2EEを完全に置き換えたりできるはずです。
- 結果として得られる永続層は、プロジェクト間で再利用可能である必要があります。これは、現在進行中のアプリケーションアーキテクチャの一部である必要があります。
問題を特定したら、適用するパターンを決定できます。J2EEパターンの場合、問題領域に適用されるパターンを判別し、それらに対処する必要があることに注意してください。永続性については、関連するJ2EEデザインパターンは次のとおりです（「参考文献」のSunのJ2EEデザインパターンブックを参照）。
- 値オブジェクト
- ファストレーンリーダー
- データアクセスオブジェクト
- セッションファサード
- 複合エンティティ
- 値リストハンドラー
EJBを使用するため、EJBアクセスに対処するためにビジネスデリゲートパターンとサービスロケーターパターンを含めます。
さらに、2番目と3番目のユースケースを解決するには、従来のソフトウェア開発デザインパターンが必要です。依存関係をどのようにカプセル化し、構成可能な永続化メカニズムを用意しますか？適用可能なソフトウェア開発パターンには、次のものがあります。
- 工場
- メディエーター
- 戦略
