JPAから簡単なSQLへの移行

Question

約100個の表を持つ本番アプリケーションでTopLink/EclipseLinkを使用して長年の開発を行ってきましたが、十分なだけで、実際の操作の複雑さと不確実性が増えないと判断しました。 SQL（DBUtilのようなラッパーを使用しているものなど）は、私たちのためにちょうどいい仕事をすることができます。

かなり大きなJPAアプリケーションをJPAをまだ実行しているままの状態（つまり、GUIを備えたWebアプリケーション）でJDBC/SQLに移行する方法を提案できますが、 JDBCにダウングレードしますか？

私はエンティティとDAOを持っていますが、私の実際の心配はJPAエンティティキャッシュ（プライマリ）です。JPAが単純なconnection.begin（）;エントリ... connection.commit（）;私たちがそれをなくすまで、中間では？

Answer 1

私はあなたに良いユニットと統合テストがあることを願っています。そうでなければ、これが始まるところです。

その後、最初のステップでabstract factoryを作成し、すべてのDAOとエンティティにアクセスし、クライアントからのすべてのアクセスをその工場を経由して変更することができます。このステップでは、そのファクトリの実装を提供し、具体的なファクトリJpaAccessFactoryを作成し、そのメソッドがDAOとJPAを使用して埋め込まれたエンティティを返さなければなりません。

最初の手順で何も悪くはないことがわかったとき。 2番目の手順に進みます。

工場出荷時の実装を作成するSqlAccessFactoryは、SQLを使用してDAOとエンティティ（エンティティクラスのオブジェクトは実際にはDAOです）を埋めます。いくつかの単位テストを書くと、両方の工場が使用され、JpaAccessFactoryとactualによって提供されるexpectedを使用してアサートを行います。SqlAccessFactoryによって提供されます。

テーブルのファクトリメソッドとそのすべての依存関係をSqlAccessFactoryに実装すると、このメソッドによって提供されるDAOまたはエンティティを使用するクライアント/ページに新しいファクトリを使用して取得されます。あなたはこれを設定可能にすることができますので、魔法使いの工場を変更するコードを変更する必要はありません。これはまた、何かがそうではないことが分かった場合、簡単に元に戻すことができるという利点があります。

ファクトリメソッドの魔女は、まだ私は、これはいくつかのヒント1と起動方法を与える願っています例外

throw new UnsupportedOperationException 
    ("Not yet implemented, please configure your client/page to use JPA."); 

を投げることができSqlAccessFactoryに実装されていません。

Answer 2

アイデアは、リポジトリレイヤを導入することです。 JPAでリポジトリを導入し、コアAPIを迅速に実装します。おそらく、既存のデータアクセスコードを再利用するでしょう。

ポイントは、JPAの代わりにリポジトリを直接使用するようにアプリケーション全体をリファクタリングすることです。

さらに、別のチームがpure jdbcで実装されたリポジトリで作業し、jpc実装とjdbc実装をテストすることができます.jdbcとjpaリポジトリは同じインタフェースセットを実装するため、適合テストは明白です。要約する

、次は同時に起こる：

• あなたが実際のビジネスコード
• のニーズを満たすためにあなたの界面層を設計し、既存のJPAコード
• とリポジトリを実装し、使用する独自のビジネスコードをリファクタリングリポジトリ
• jdbcで同じリポジトリを実装し、適合性テストを実装します。

すべてです。十分な信頼性がある場合は、リポジトリの実装をjdbcリポジトリに切り替え、jpaリポジトリを下位互換性テストのためだけに保つだけです。