私は自分でいくつかの調査を行い、基本的な概念を理解しました。しかし、洞察の中には、実際の経験を通してしか得られないものもあります。
新しいフレームワークを学ぶ価値があるmyBatisの利点は何ですか?
どのような場合に使用を避けますか?
あなたが達成しようとしていることを考えてください。通常、 Command Query Response Segregation モデルは、複雑なドメインに適しています。
その理由は、通常、次の2つのいずれかを実行しようとしているためです。
Hibernateはケース1でうまく機能し、POJOを作成して永続化/更新するだけで済みます。ドメインが非常に大きい場合を除き、これもすばやく実行されます。
myBatisは、単にクエリが必要なフェッチクエリ(ケース2)に最適です。 Hibernateはオブジェクトグラフ全体をロードしようとするため、LazyLoadingトリックを使用してクエリを調整し、大規模なドメインで機能し続けるようにする必要があります。これは、エンティティオブジェクトを返さない複雑な分析クエリを実行する場合に重要です。この場合、HibernateはSqlQueryとBeanトランスフォーマーのみを提供し、BigDecimalなどの巨大なデフォルトタイプを備えていますが、myBatisは簡単なPOJO非エンティティーに簡単にマップできます。
これら2つのケースは、ドメインデータを変更するCommandsとResponsesデータをフェッチしたいだけの場所。
したがって、これらの2つのケースと、アプリケーションが行うことを検討してください。単純なドメインがあり、情報を取得するだけの場合は、myBatisを使用します。複雑なドメインがあり、エンティティを永続化する場合は、Hibernateを使用します。両方を行う場合は、ハイブリッドアプローチを検討してください。これは、何千ものエンティティがプロジェクトを管理するために使用するプロジェクトで使用しています。 ;)
MyBatisはSQL中心です。 SQLステートメントの呼び出しとオブジェクトツリーへの結果(テーブル)のマッピングに役立ちます。
主な利点は、それがORMではないことです。テーブルをオブジェクトにマップしないので、オームインピーダンスの不一致が発生しません。複雑なデータベースやレガシーデータベース、またはストアドプロシージャやビューなどのdb機能を使用するのに適しています。
非常にシンプルで簡単に習得できるので、熟練度の低いチームにも適しています。その間に休止状態の第一人者がいる必要がないためです。
Jpetstore 6をご覧ください http://mybatis.org/spring/sample.html
質問参照 から 私のコメント への変換のため、ここに書いたのはこれです。
まず、元の質問のコンテキストから導き出されます。他の状況では別のアドバイスをすることができます。私にMyBatisを提案させたポイントはこれです:
...パフォーマンスの問題が発生しました。
データベースのパフォーマンスを向上させるために、プレーンJdbcを優先して休止状態を解除することにしました...
過去のプロジェクトの1つで、私たちのチームは、あなたが説明したような理由でHibernateからの移行を検討してきました。あなたと同じように、JDBCに切り替えるつもりでしたが、別のプロジェクトの同僚からMyBatisが勧められました。チームは、問題が発生した場合に備えて、JDBCをフォールバックオプションとして保持しながら、試してみることにしました。
その瞬間、私はMyBatisについて何も知りませんでしたが、JDBCが十分に機能することを確認するのに十分な経験がありました。それにもかかわらず、私はMyBatisを試すという考えを強く支持していました。主な理由は、私の過去の経験によれば、JDBCで記述しなければならないボイラープレートコードの量は非常に困難であることです。
とにかく、私たちはMyBatisを試してみましたが、宣伝どおりに機能しました。だからあなたが尋ねるコメントを書いたんです。
テクノロジーの詳細な概要を説明したり、どういうわけかその優位性を称賛したりする場合は、申し訳ありませんができません。できれば-短いコメントではなく、元の質問への別の回答でそれをすでに書いています。私はその当時MyBatisについて何も知らなかったと述べました-ええと、それについてはまだほとんど知識がありません。 Hibernateからの移行は他のチームメンバーによって行われ、私が取り組んでいるコードには影響しませんでした。私が思い出した重要なポイント(コメントに基づいて)、つまり1)MyBatisがHibernateで発生した問題を解決した、2)独自の問題が導入されなかった、3)ボイラープレートコードの作成を回避できたJDBCに切り替える場合に備えて期待していた。それで全部です。