前回、Hibernate について多くの不満を聞きました。実際、Hibernate についてもいくつかのつらい経験があります。それで、イービーンとシエナについて読みました。
どちらも興味深いアプローチです。残念ながら、データベース アクセス レイヤーは非常に簡単に作成できますが、プロジェクトが大きくなり、優れたデータベース テーブルを処理する必要がある場合、それが適切かどうかはわかります。そのため、そのようなツールを評価するのは非常に困難です。Hibernate はよく知られており、問題を解決できることは間違いありません。時には多くのことを学ぶ必要がありますが、それは解決できます。
イーブイはどうですか？実際のアプリケーションはありますか? どのデータベースがサポートされていますか? 信頼できますか？
もう少し検索したところ、ORM フレームワークは他にもたくさんあることがわかりました。少なくとも 1 つの信頼できるフレームワークはありますか?
Rob (Ebean コミッター) はこちら。
イービーンは現在4歳以上です。今ではかなり成熟していると言えます。サポートされている DB には、Oracle、MySql、Postgres、H2、および SQL Server (最近では SQLite) が含まれます。Ebean は、Autofetch (自動クエリ チューニング) など、他の ORM にはないことを行っているため、それが「成熟度評価」にどのように適合するかはわかりません。IMO Ebean コミュニティは比較的小さいので、おそらく Ebean の Google グループにアクセスして参加する必要があります。
実際のアプリケーションはありますか? はい。しかし、それについては Ebean コミュニティに尋ねるのが最善です。確かに、バッチ処理 (バッチ サイズ、トランザクションのカスケード永続化のターンなど) と、JPA などでは見られない大規模なクエリのサポート (Hibernate のセッションレス サポートで同様のことが得られる可能性があります) の優れたサポートがあります。
とにかく、これがあなたの質問のいくつかの小さな部分に答えるかもしれません。
乾杯、ロブ。
私は現在、Siena の開発者ですが、それほど長くはありません。私がこのプロジェクトの開発者になった理由を説明させてください。私は Play+GAE を使いたいと思っていたので Siena に行きました。Siena は GAE DB の良いスタートに見えたので、JDO/JPA を本当に避けたかったのです。それから、私は Siena の単純明快で簡単なアプローチと非常にシンプルな API を高く評価するようになりました。JDO のようなオールインワンの抽象化レイヤーや、JPA のような最高の標準 DB API のふりをしているわけではありません。Python/Ruby の DB API について考えさせられました。これは私の見解にぴったりです。問題の大部分を解決できるシンプルな DB API が必要であり、より複雑な問題が発生した場合は、DB API を使用します。下位層の API ですが、休止状態などの抽象化層ではありません。
私のコードを GAE DB または JDBC で動作させる可能性も良い面でした。繰り返しになりますが、SQL と NoSQL は実際には互換性がないため、Siena は両方の世界でまったく同じものを提供するふりをしません (ただし、ORM は実際には SQL モデルに準拠していません :))。しかし、繰り返しますが、複数の DB で同じ API に依存できることは非常に実用的です。
最後に、ライブラリは 1 つの jar であり、それを使用するためにユニバース全体を取得する必要はありません。
この素敵な小さな冒険に参加したかったので、私は次第に Siena のコミッターになりました。現在、シエナ チームは、同じシンプルな API を維持しながら新しいバージョンに取り組んでおり、新しい興味深い機能をもたらし、すべてのバックエンド コードを大幅に改善して、新しい DB サポートの拡張をさらに容易にしています。Siena はユーザー エクスペリエンスによって駆動される実用的な API であり、それが私が気に入っている理由です ;)
パスカル
イービーンとシエナの他に：
不変オブジェクトのCRUDに焦点を当てたJIRMを試すことができます（はい、私は作成者です）。
jOOQや Joistもあります。
ドメインオブジェクトは不変であり、継承、実装、および/または「拡張/装備」されていないため、JIRMはDTOの数を最小限に抑えていると思います。これは、シエナとイービーンと同じではありません。
また、オブジェクトは不変であるため、オブジェクト全体ではなく、列ごとの更新に重点が置かれています。これは、今日の AJAX インターフェイスを考えるとより理にかなっています (古い POST Bean モデル全体と比較して)。
私たちは、それ自体が ORM ではなく、永続化マネージャーの別のクラスである SQL Mapper であるMyBatisで本当に素晴らしい経験をしました。これを使用して、SQL ステートメントから開始し、結果行を POJO にマップする方法を指示します。概念的に理解しやすく、内部で魔法があまり使われていないため調整が容易です。SQL に慣れているか、確立されたスキーマを使用する必要がある場合に最適です。
たとえばJBoss（www.jboss.org）でEB3を使用するのはどうですか？