エンタープライズアプリケーションは、多くの場合、大量のデータの収集、処理、変換、レポートなどの操作を処理します。これらのデータは通常、特定の場所にあるデータベースサーバーに保存され、オンデマンドで取得されます。アプリケーションは、データベースからのデータを処理し、最終的にクライアントが使用できるようにそれらを提示する責任があります。しかし、異なるアーキテクチャ間のデータ交換を軽減することに伴う複雑さは、開発者が直面する本当の課題です。問題の核心は、アプリケーションの開発に使用されるコードとデータの永続性に使用されるストレージモデルの間のデータ移動の複雑な関係を緩和することにあります。つまり、Java言語のオブジェクト指向の性質とリレーショナルデータベースモデルという、2つの譲歩しないモデル間のシームレスな相互作用のためのメカニズムを作成するというアイデアです。
データベースの基本API
Javaプラットフォームには、JDBCAPIの形式でデータベースシステムと連携するための標準APIがすでに用意されています。これらのAPIはデータベースの操作に優れており、Java言語からデータベースと便利に対話するために必要な手段を提供します。しかし、問題はJavaがオブジェクト指向言語であるということです。 JDBCは、データベースの相互作用のためのコアAPIを提供し、データベーステーブルの行と列の構造をエンティティクラスに変換することに重点を置いていません。したがって、JDBCAPIの上で機能するAPIのレイヤーが求められます。永続性API（JPA）は、操作の流動性を活用することを目的として、アーキテクチャ的に異なる2つのモデルを軽減します。 APIは、データベースリレーションテーブルをPOJOとして表すのに役立ち、Javaコード全体で同じように扱うことができます。コアJDBCAPIはバックグラウンドで動作して、通信とデータベース接続の複雑さを処理しますが、JPAを使用すると、Java言語のオブジェクト指向コードに従って処理を実行できます。ただし、リレーショナルデータベースとJava間のデータマッピングは簡単な作業ではありません。
Java永続性のサポート
一般的なリレーショナルデータベースでは、情報は行と列の構造で保存されます。データベースシステムとJavaアプリケーションのオブジェクトモデルとの間のデータ交換は困難です。これは、Javaが単一のエンティティを、それらに適用される一連のプロパティと操作によって示されるクラスとして指定するためです。したがって、2つの異なるアーキテクチャ間の動作の不一致に準拠するには、Javaプログラマーは多くのコード行を作成する必要があります。これらのコード行は、データベーステーブルの行と列のデータをJavaオブジェクトに変換するのに役立ちます。ただし、多くの場合、これらのコード行は繰り返しすぎて、ソースコードにボイラープレートコードが追加されます。これは望ましくなく、再利用性の基本的なオブジェクト指向の原則に違反します。巧妙なコードは多くの逆境を緩和するかもしれませんが、それは簡単な解決策ではありません。サードパーティソリューションの出現は、データベースデータをJavaオブジェクトにマッピングする際の休息ですが、それらは標準ではありませんでした。各ベンダーの実装は、それぞれかなり異なります。これはすべて、状況がJavaプラットフォーム自体からの標準の永続性APIライブラリを要求したことを意味します。これにより、特にJavaのオブジェクト指向ドメインモデルとデータベースシステムの間のギャップを埋めるために、Java Persistence API（JPA）が導入されました。
独自のソリューション
オブジェクトリレーショナルソリューションはかなり前から存在しており、Java言語自体が誕生する前からさかのぼることを理解してください。たとえば、OracleのTopLink製品は、実際にはSmalltalkでキックスタートし、その後Javaに切り替えました。現在、これはOracleAS、WebLogic、およびOC4Jサーバーの一部です。実際、最も人気のある2つの永続化APIは、商用ドメインの独自標準であるOracleのTopLinkと、オープンソースコミュニティドメインのHibernateでした。その後、Hibernateの人気が高まり、標準のJPAライブラリの作成に大きな影響を与えました。
データマッパー
データマッパーは基本的に、MartinFowlerが著書Patterns of Enterprise Application Architectureで提案したアーキテクチャパターンです。 、2003。これは、オブジェクトリレーショナルの問題に対処するための部分的な方法を提供します。マッパーは、プレーンJDBCとフル機能のオブジェクトリレーショナルマッピングソリューションの間のカテゴリに分類される戦略を作成するのに役立ちます。ここで、アプリケーション開発者は、データマッパーメソッドを使用してデータベーステーブルをJavaオブジェクトにマップするための生のSQL文字列を作成します。 Apache iBatisと呼ばれる、SQLデータベースとJavaオブジェクト間のマッピングのこの手法を使用する一般的なフレームワークがあります。 ApacheiBatisプロジェクトは現在非アクティブであると宣言されています。ただし、Apache iBatisの元の作成者は、プロジェクトをMyBatisに転送し、活発に開発中です。
MyBatisのようなデータマッパーフレームワークを使用する他のオブジェクトリレーショナル問題ソリューションとは異なり、データベースとのSQLトランザクションを完全に制御できます。これは軽量のソリューションであり、本格的なORMフレームワークのオーバーヘッドを伴いません。ただし、データマッパーには問題があります。オブジェクトモデルに加えられた変更は、データモデルに影響を及ぼします。結果として、SQLステートメントに直接大幅な変更を加える必要があります。フレームワークの最小限の性質は、開発者が必要に応じて新しい変更や修正を組み込むのに役立ちます。データマッパーは、最小限のフレームワーク、明示的なSQL処理、および開発者による変更のためのより詳細な制御が必要な状況で特に役立ちます。
JDBC
JDBC（Java Database Connectivity）は、MicrosoftのODBC（Object Database Connectivity）仕様のJava固有のバージョンです。 ODBCは、任意の言語またはプラットフォームから任意のリレーショナルデータベースを接続するための標準です。 JDBCは、Java言語に関して同様の抽象化を提供します。 JDBCは、SQLを使用してデータベースと対話します。開発者は、バックエンドデータベースの構文仕様に従ってDDLまたはDMLクエリを作成する必要がありますが、Javaプログラミングモデルを使用してそれらを処理します。 JavaソースとSQLステートメントの間には緊密な結合があります。生のSQLステートメントに頼り、必要に応じて静的に操作することができます。静的な性質のため、変更を組み込むことは困難です。さらに、SQLダイアレクトはデータベースベンダーごとに異なります。 JDBCは、Java言語のオブジェクトモデルではなく、データベースにハードワイヤードされています。したがって、特にJavaソースコードからのデータベースの相互作用が増えると、すぐに操作が面倒になります。ただし、JDBCはJavaでのデータベースの永続性の主要なサポートであり、高レベルのフレームワークの基盤を形成します。
EJB
J2EEを使用するEnterpriseJavaBean（EJB）は、エンティティBeanの形式でJava永続性の分野にいくつかの新しい変更をもたらしました。アイデアは、データベースの永続性の複雑さに直接介入することから開発者を隔離することでした。インターフェイスベースのアプローチを導入しました。永続性、トランザクション管理、およびビジネスロジック委任の実装を生成するための専用のBeanコンパイラがあります。エンティティBeanの構成には、特殊なXMLデプロイメント記述子が使用されました。問題は、EJBが物事を単純化するのではなく、多くの複雑さを組み込んだことです。その結果、Enterprise JavaBeansクエリ言語（EJB QL）の導入など、その後の多くの改善にもかかわらず、すぐに人気を失いました。
Javaデータオブジェクト
JDO（Java Data Object）は、EJB永続性モデルが直面する問題に対処しようとしました。透過的な永続性のためのAPIを提供し、EJBおよびJ2EEで動作するように設計されています。 JDOは、オブジェクト指向データベースに大きく影響され、サポートされている製品です。永続オブジェクトは、開発者が特別なクラスやインターフェースを実装する必要のないプレーンなJavaオブジェクトです。オブジェクトの永続性の仕様は、通常、XMLメタファイルで定義されます。サポートされているクエリ言語は、本質的にオブジェクト指向です。多くの優れた機能にもかかわらず、JDO仕様は開発者コミュニティの間であまり受け入れられませんでした。
Java Persistence API
商用ドメインとオープンソースドメインの両方に、独自の永続化フレームワークがいくつかありました。 HibernateやTopLinkなどのフレームワークは、アプリケーションのニーズを非常にうまく満たしているように見えました。その結果、JPAと呼ばれる標準の永続性モデルを作成するための主要な基盤としてHibernateが選択されました。
JPAは、POJOを使用してオブジェクトリレーショナルマッピングを作成するのに役立つ標準の軽量Java永続化フレームワークです。 JPAは、永続性をスケーラブルなエンタープライズアプリケーションに統合するのにも役立ちます。 JPA永続性モデルの使用に関心のあるアプリケーションに公開する必要のあるクラスはごくわずかであるため、使いやすいです。 POJOの使用は、おそらくJPAの最も興味深い側面です。これは、オブジェクトについて特別なことは何もないことを意味します。それはそれを持続可能にします。オブジェクトリレーショナルマッピングはメタデータ駆動型です。これは、コードの内部または外部でアノテーションを使用して実行できます。 XMLを使用します。
JPAの永続APIは、永続オブジェクトとは別のレイヤーとして存在します。ビジネスロジックは通常、APIを呼び出し、永続オブジェクトを渡してそれらを操作します。アプリケーションは永続APIを認識していますが、POJOである永続オブジェクトはその永続機能を完全に認識していません。
結論
この記事では、データマッパー、JDBC、EJBなど、JPAの導入前に利用可能だった独自のソリューションの概要を説明しました。このアイデアは、JPAの作成につながった理由と、その前身の永続的な手法について少し洞察を与えることです。乞うご期待;以降の記事では、JPAAPIのより具体的な側面について詳しく説明します。