新しいJava永続化ツールについてどう思いますか。それは実際にはORMではありませんか？[閉まっている]

Javaでの永続性

過去数年にわたって、EJB 2.0、Hibernate、JPA、および自家製の概念などを使用して、Javaの永続性抽象化の分野での経験を集めてきました。彼らは、急な学習曲線と多くの複雑さを持っているように思えました。さらに、SQLの大ファンとして、多くの抽象化モデルがSQLを抽象化しすぎて、SQLではなく非常に優れた概念である「基準」、「述語」、「制限」などの概念を作成すると考えました。

Javaでの永続性抽象化の一般的な考え方は、RDBMSがオブジェクト指向の世界と何らかの形で一致するオブジェクトリレーショナルモデルに基づいているようです。ORM討論は常に感情的なものでした。すべての人に適した単一の解決策は存在しないようです。そのような解決策が存在する可能性があるとしてもです。

jOOQ

ORM関連の問題を回避する方法の個人的な好みは、リレーショナルの世界に固執することです。データモデルのパラダイムの選択は、個人的な好みであるため、または具体的な問題に最適なデータモデルの問題であるため、議論のトピックではありません。私が始めたいと思う議論は、jOOQと呼ばれる私自身の永続化ツールに関するものです。私はjOOQを設計して、最新の永続化ツールが持つ利点のほとんどを提供します。

• SQLに基づくドメイン固有言語
• 基礎となるデータベーススキーマをJavaにマッピングするソースコード生成
• 多くのRDBMSのサポート

いくつかの最新の永続化ツールにあるいくつかの機能を追加します（間違っている場合は修正してください）：

• 複雑なSQLのサポート-ユニオン、ネストされた選択、自己結合、エイリアス、ケース節、算術式
• 非標準SQLのサポート-ストアドプロシージャ、UDT、ENUMS、ネイティブ関数、分析関数

詳細については、ドキュメントページhttp://www.jooq.org/learn.phpをご覧ください。LinqはSQL専用に設計されているわけではありませんが、Linq for C＃に非常によく似たアプローチが実装されていることがわかります。

質問

さて、私はSQLの大ファンだと言って、他の開発者がjOOQ（またはLinq）に対する私の熱意を共有するかどうか疑問に思います。永続性抽象化へのこの種のアプローチは実行可能なものですか？あなたが見るかもしれない利点/欠点は何ですか？どうすればjOOQを改善できますか？また、あなたの意見には何が欠けていますか？概念的または実際的にどこで間違ったのですか？

批判的だが建設的な答えを高く評価

議論は感情的なものであることを理解しています。すでに同様のことを行う多くの素晴らしいツールがあります。私が興味を持っているのは重要ですが、あなた自身の経験や読んだ記事に基づいた建設的なフィードバックです。

あなたは正しい軌道に乗っており、あなたのソリューションを継続すべきだと思います。以前の批判のいくつかは過度に厳しいですが、いくつかの正当な点が指摘されています。

私も、自分のニーズに合ったフル機能のORMソリューションを探していましたが、見たすべてのソリューションが不足していました。それぞれに長所と短所がありますが、私が望んでいたすべてを本当に実現したものはありませんでした。これらのソリューションに対するあなたの批判に同意します。つまり、それらは一般に複雑で、学習曲線が急勾配であるということです。

最有力候補は事実上の標準であるHibernateでなければなりません。フル機能、堅牢、十分にテストされています。私はそれを尊重し、それが何であるかを感謝しています。さて、プログラミングコミュニティの半分を傷つける危険性がありますが、私はまた、それが肥大化した複雑な非パフォーマンスコードであると言わなければなりません。私はかなりの時間をその腸でつついて、それをデバッグして理解しようとしましたが、私は見たものに感銘を受けませんでした。そうは言っても、良いORMを探している人の出発点としてそれをお勧めします。単純なCRUDには優れていますが、データマイニングや数値計算などのパフォーマンスの高いバルククエリには使用しません。

残念ながら、私のアプリケーションはより多くの処理能力がありますが（CRUDもあります）、自分のアプリケーションをロールバックすることにしました。私は最初から、他のソリューションと比較して同等以下であることを知っていましたが、それで十分であり、必要なパフォーマンスが得られました。これが本当に素晴らしい部分です。それはあなたのソリューションに非常によく似ています！

これが私があなたが最も正しくしたと思うことです。あなたはあなたの根底にある信念を一種の使命声明として述べました、そして、それらの信念は正しいです。私も明らかにこの問題についてかなりの時間を費やしてきましたが、解決するのは難しいものです。しかし、時間が経つにつれて、プログラミングコミュニティはそれをよりよく理解するようになり、より良いソリューションを作成できると思います。これまでのすべての努力（特にHibernate）に称賛を寄せていますが、私たちはもっとうまくやれると思います。

あなたのソリューションは問題をより洗練させますが、それはその一部を解決するだけです。階層化されたアプローチは、私たちが望むものすべてを提供してくれると思います。あなたが思いついた/ IMOは、基礎層です。あなたが提案したように、このレイヤーはデータベーススキーマに基づいて自動的に生成されるのが最適だと思います。これは、データベースに直接マップされる非常に単純なリレーショナルオブジェクトモデルである必要があります。データはコードよりもはるかに長く持続するのは正しいので、このレベルでは、データはコードを駆動し、逆はそうではありません。CRUDとパフォーマンスのバルククエリをサポートします。おそらく、このレイヤーに何らかのL1キャッシュを実装するでしょう。

ただし、他のORMソリューションが優れているのは、基礎となるデータベースの実際の構造にあまり依存しない方法でオブジェクトを定義できることです。この機能のために、別のレイヤーを作成します。必然的に、この層はより抽象的になり、できればよりシンプルになり（機能が失われることを犠牲にして）、前の層の上に構築されます。L2キャッシュを利用する場合があります。

レイヤーを追加することもできますが、重要な点は、ライブラリに複数のエントリポイントを提供することで、あらゆるニーズを満たすことができるということです。選択したオブジェクトに直接マッピングするシンプルなCRUDソリューションが必要な場合は、最上位層に構築できます。より強力で高性能なものを探しているが、複雑さを増すことを望んでいる人のために、彼らは下層にプラグインすることができます。特別なクエリ言語を作成するのではなく、この目的でクエリビルダーオブジェクトを公開します。また、コードは階層化されているため、その機能は特別なパススルーなしで自然に存在します。

あなたはその空間を理解しており、車輪を再発明しているのではなく、わずかに異なるニッチにヒットしていると思います。そして率直に言って、これはとにかく改善を使用できるホイールです。あなたは過去の強豪と争う困難な戦いに直面していますが、あなたの解決策が良ければ、そしてそれがその方向に向かっていると思うなら、それはそれ自身のメリットで人気を得るでしょう。

「そこには多くの魔法の弾丸があり、素朴な開発者の不足はありません。」

違反はありません。この空間で何が行われたかを完全に理解していないため、いくつかの車輪を再発明しています。すでに利用可能な素敵な洗練されたホイールとして良いか有用。

この種のAPIを適切に使用するシナリオの1つは、ほとんどのORMで使用できないデータベースに依存しないSQLビルダーが必要な場合です。私がそれを必要としていた大きな状況の1つは、レポートの生成です。オブジェクト指向の方法でSQLを構築し、このSQLをさまざまなデータベースで実行してテストする必要がありました。Hibernateと他のORMは構成に非常に依存しているため、XMLに関連付けが存在しないテーブルを結合できないように、SQLの構成を制限しています。私が開発しているレポートモジュールでは関連付けが可能なため、別の方法を探していました。それからJOOQに出会いました。それは私の問題を解決するだけです。読み取り専用アクセスが必要なだけで、休止状態のような苦痛なデバッグの問題に遭遇することはありません。

私は実際に、一般的なPOJOの方法ではなく、データをモデル化する別の方法を開発し、SQLを構築するレイヤーである基盤の1つとしてJOOQを使用することを計画しています。そのため、JOOQに加えて、HashMapsを使用してデータ/エンティティをより柔軟にモデル化する方法を作成する予定です。私の設計では、フロントエンドとバックエンドの設計を1つのエントリポイントで簡単に統合できますが、上記のコメントで述べたように、さまざまなレイヤーを使用してフレームワークを完成させます。JOOQは、私自身のプロジェクトのように、非常に良い役割を果たします。これは、基盤または柱の1つとして機能します。

だから良い仕事ルカを続けてください！

ツールを正しく理解していれば、ORMのようなSQL機能（ORM）へのマッピングを実装するオブジェクトをマッピングするのではなく、オブジェクトを概念的なSQLフレームワークに直接マッピングします。 ORMは通常あなたに与えないでしょうか？

あなたが解決しようとしている問題がわからない。あなたのツールはSQLの深い知識を必要とするので、人々はSQLを使うだけではありませんか？それはあなたが除去しようとしているグルーコードですか？単純な文字列ではなく、APIモデリングを通じてSQLクエリの検証を改善しますか？

JOOQの例がSQLのLISPバージョンのように見えることを認めなければなりません。それは悪いことではありません:)、そして高度なもののいくつかが面白いとわかりますが、あなたがリストする利点は、高度になるにつれて徐々に消えます（特定のSQLの内部聖域にもっと多くの構成、より抽象的なもの、より深く染み込んでいます）エンジンなど）

ほとんどのORMで見逃したい提案の1つは、オブジェクトの相互作用をバックエンド（SQL、NoSQL、トピックマップ、RDFなど）に変換する非リレーショナルな方法でオブジェクトを処理できるフレームワークです。）これは、SQL相互作用、方言、およびリレーショナル思考の詳細ではなく、使用されるモデルのキャッシュを必要とします。

もちろん、私見。:)