新しいJava永続化ツール、それは実際にはORMではない）についてどう思いますか？
Javaでの永続性
過去数年にわたり、EJB 2.0、Hibernate、JPA、および自社開発の概念などの概念を使用して、Javaの永続性抽象化の分野で経験を積み重ねてきました。彼らは私に急な学習曲線と多くの複雑さを持っているように見えました。さらに、SQLの大ファンとして、多くの抽象化モデルはSQLよりも抽象化が多すぎて、「基準」、「述語」、「制限」などの非常に優れた概念ですが、SQLではない概念を作成していると思いました。
Javaでの永続性抽象化の一般的な考え方は、RDBMSがOO世界と何らかの形で一致しているオブジェクトリレーショナルモデルに基づいているようです。ORM-皆に合う単一の解決策が存在するようには見えないので、そのような解決策が存在する可能性さえあれば、議論は常に感情的なものでした。
ジョーク
ORM関連の問題を回避する方法についての私の個人的な好みは、関係の世界に固執することです。ここで、データモデルパラダイムの選択は、個人的な好みであるため、または具体的な問題に最も適したデータモデルの問題であるため、議論のトピックとすべきではありません。私が始めたい議論は、 jOOQ と呼ばれる私自身の永続化ツールを中心にしています。私はjOOQを設計して、最新の永続化ツールが持つ利点のほとんどを提供しました。
- SQLに基づくドメイン固有言語
- 基になるデータベーススキーマをJavaにマッピングするソースコード生成
- 多くのRDBMSのサポート
いくつかの最新の永続化ツールが持っているいくつかの機能を追加します（間違っている場合は修正してください）。
- 複雑なSQLのサポート-ユニオン、ネストされた選択、自己結合、エイリアス、case句、算術式
- 非標準SQLのサポート-ストアドプロシージャ、UDT、ENUMS、ネイティブ関数、分析関数
詳細については、ドキュメントページをご覧ください： http://www.jooq.org/learn.php 。 LinqはSQL専用に設計されているわけではありませんが、C＃のLinqには非常に類似したアプローチが実装されていることがわかります。
質問
さて、私は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に出会いました。それは私の問題を解決するだけです。私は読み取り専用アクセスを必要としましたが、Hibernateのような苦痛なデバッグ問題に遭遇することはありません。
私は実際には、一般的なPOJOの方法ではなく、データをモデリングする別の方法を開発し、SQLを構築するレイヤーである基盤の1つとしてJOOQを使用することを計画しています。そこで、JOOQの上に、HashMapを使用してデータ/エンティティをモデリングする、より柔軟な方法を作成することを計画しています。私の設計では、フロントエンドとバックエンドの設計を1つのエントリポイントで簡単に統合できるようにしますが、上記のコメントのように、さまざまなレイヤーを使用してフレームワークを完成させます。 JOOQは本当に私のプロジェクトのように非常に良い役割を果たすでしょう。それは基盤または柱の1つとして機能します。
いい仕事を続けてください！
私があなたのツールを正しく理解している場合は、SQL機能（ORM）へのマッピングを実装するオブジェクトをマッピングするのではなく、オブジェクトを概念的なSQLフレームワークに直接マッピングします。 ORMは通常あなたに与えないでしょうか？
あなたが解決しようとしている問題がわからない。ツールにはSQLに関する深い知識が必要なので、SQLを使うだけではないでしょうか。それはあなたが取り除こうとしているグルーコードですか？単純な文字列ではなく、APIモデリングによるSQLクエリの検証の改善？
私はあなたのJOOQの例がSQLのLISPバージョンのように見えることを認めなければなりません。それは悪いことではありません:)そして私はいくつかの高度なものが面白いと思いますが、あなたがリストする利点は、高度になるにつれて徐々に消えます（より多くの設定、抽象的なものではなく、特定のSQLの内部の聖域に染み込んでいます）エンジンなど）
ほとんどのORMで見逃していることを確認したい1つの提案は、オブジェクトを非リレーショナルな方法で処理し、オブジェクトの相互作用をバックエンドが何であれ（SQL、NoSQL、トピックマップ、RDFなど）に変換できるフレームワークです。 。）これは、SQLの相互作用、方言、および関係の考え方の詳細ではなく、使用されるModelのキャッシュを必要とします。
もちろん、私見。 :)