実装に依存しないことは本当に価値がありますか？

現在、Tomcat、Spring 4、Spring Security、MySQL、およびJPA w / Hibernateを使用して取り組んでいるプロジェクトがあります。

私は、ORMプロバイダーの基盤となる実装をシームレスに、または少なくとも痛みを軽減するために、JPAを選択しました。これは、実装（JAX-RS）よりも仕様を精神的に使用しているということは、Java開発コミュニティのデフォルトの観点であると言えます。

これが本当にやりがいのある仕事であるかどうか興味があります。Hibernateを直接使用した場合、メインのJPA仕様の一部ではない機能を使用できるため、ある程度のパワーが得られると確信しています。

私の懸念の一部は、YAGNIのアイデアから来ています。私は本質的に特定のスタイルと方法でプログラミングしているため（Hibernateの代わりにJPAを使用）、将来のある時点でORM実装を交換できます。私は製品の寿命にわたってこれが起こることをひどく疑っているので、私は本質的に私はおそらく恩恵を決して享受しないものに努力しています。

あなたの考えは何ですか？JPAのようなものになると、「インターフェースへのプログラミング」は価値がありますか？実際に製品のORM実装全体を交換したことはありますか？とにかくJPAリークのようなものからの抽象化を完全に回避できたことがありますか？個人的には既にデータベーステーブルをクリーンアップするために単一のネイティブSQL呼び出しがあり、JPA仕様に組み込まれているもの（メソッドのプレフィックスの取得/設定、およびMEMBER OFの違い） / IN。これは、基礎となる実装に自分自身をバインドするだけで、回避する機会を与えてくれます。

将来のある時点で、ORM実装を交換できるようにします。私はそれが製品の寿命にわたって起こることをひどく疑っているので、基本的に私はおそらく私が多分決して恩恵を受けない何かに努力をしています

私の経験では、典型的なエンタープライズプロジェクトは決して交換されません。

1. データベース
2. ORM
3. 言語

数字はわかりませんが、私が見た2層アプリの実装と変更の割合は、おそらく10％未満でしょう。発生した場合、それはまれであり、通常、プロジェクトの最初の2〜3か月以内に、まだ発見モードになっているときに発生します。私が知っているほとんどのシステムは、8〜10年後も元のプラットフォームで実行されています。

ORMを交換するよりも、私が見たものをもっと知りたいですか？パフォーマンスの問題により、ORMを完全に削除してSQLにドロップします。だから、どんな場合でも、あなたは何かを書き直そうとします。

実装に依存しない限り、それは神話です。それは本当に馬鹿げています。したがって、私のアプローチはデータ層を採用することです。それをあなたの言語とデザインのファーストクラスの一部にしてください。それは、より幸せで、より成功したプロジェクトになります。

その価値はありますか？
それはアプリケーションに完全に依存します。
単一の会社の内部アプリケーションを作成している場合は、忘れてください。このデータベースは、アプリケーションを数年、おそらく数十年も存続させます。
もちろん、データベースが近い将来他の何かに置き換えられる予定であることを最初から理解するように与えられていない限り。
異なるデータベースエンジンを持っている可能性のある顧客に販売するためにそれを作成し、複数のデータベースエンジンをサポートする必要があるという要件がある場合、それは理にかなっています。

その場合、Javaアプリケーションを作成するほとんどの人にとって、それはほとんど無関係です。

私の経験から：いいえ、 JPA / Hibernateの場合は価値がありません。

JPAのようなものになると、「インターフェースへのプログラミング」は価値がありますか？

それはJPAとは特に関係ありません。Hibernateの「インターフェースへのプログラミング」を実行できます。これは、標準の下でフレームワークを隠すことではなく、SOLIDについてです。

実際に製品のORM実装全体を交換したことはありますか？

はいといいえ。当社の製品の1つは、部分的にHibernateからjOOQに移行しました（JPAとは関係ありません）。@codenheimが述べた「典型的なエンタープライズプロジェクト」ではなかったため、交換が可能になりました。

Hibernateを別のJPA準拠のORMと交換しても意味がありません。

とにかくJPAリークのようなものからの抽象化を完全に回避できたことがありますか？

いいえ。JPAとHibernateの両方が非常に複雑であるため、不可能です。とにかく、Hibernateのパフォーマンスの問題と設計上の欠陥に対処する必要があります。

ここで逆張りの音を立てる危険性があるので、私は言う、はい、それは価値があります。そしてそうではありません。

ORMまたはデータベースプロバイダーを切り替える際の問題はそれほど大きくありません。それは、関心の分離とアジャイルの維持という問題です。

ライブラリの実装の詳細に依存し始めると、懸念のますます深い絡み合いを作成し始めます。

ORM実装がHibernateであることがわかっている場合、この知識はアプリケーションのアーキテクチャ全体を浸透させ始めます。また、Hibernateが以前に行ったようにHibernateまたはJPAを徹底的に置き換える新しいテクノロジーが登場すると、依存関係が予想よりもはるかに深くなっていることがわかります。

データベースやトランザクションなどの複雑な処理はすべて、アプリケーションの残りの部分で簡単に無視できるので、モデルをどこかで永続化するという懸念を完全に隠しておく方がはるかに優れています。そのリモートダークコーナーでは、必要に応じて特定の実装の詳細を結び付けることができます。これは実際には問題ではありません。

実装にとらわれないことの問題は、開発者としての時間において、どちらの方法でも時間を無駄にすることです。

私はインターフェースへの書き込みに多くの時間を費やしたいくつかのプロジェクトを書きました。

また、誰も変換する必要がないと予想していたソフトウェアを変換する時間を無駄にしました。

私がしなければならない唯一の本当の観察は、前者がはるかに痛みが少ないということです。