どのようJPA永続化フレームワークと選択MyBatisの

まず、状況説明

Javaの永続化層のフレームワークは、現在最も広く使用されているORMは、JPAとMyBatisのです。この標準を達成するための規範のちょうどJPA ORMフレームワークは、より完全である春データJPA（Hibernateが基礎を実現）、それが唯一の春環境であることができることを意味し、Springベースのデータ永続化層のフレームワークです。MyBatisのはまた、より良いようにORMエンティティリレーショナルマッピング、動的SQLとをサポートすることができる、優れたデータの永続性層のフレームワークです。

これら2つのフレームを学習する過程で、著者は、これら2つのフレームワークの長所と短所を比較したポストは、論争を引き付けるだろうたびの記事の多くを、見ました。ビューの著者の観点から、なぜ国内の開発者や開発チームは、JPA少ないでしょうか？誰かが私を攻撃しないようにするために、私は国内のインデックス検索のビットを行う傾向があり、このデータは人をだますことはできません。

青い線はMyBatisの検索ボリューム、検索ボリュームのJPAの緑です。あなたが外国人のインデックスを検索する場合、あなたは完全に異なる結果を得ることができます。だから、これはなぜですか？私たちは、JPAの機能を起動する必要があります。

JPAかは、単純な単一テーブルのSQLクエリのためにも非常にフレンドリーで、非常にインテリジェントなことができます。彼は、使用の多くに使用されているあなたの永続化層の操作方法の準備ができています。だけでも、インターフェイスメソッドなどfindByNameを書き、彼は、あなたが名前でエンティティクラスを、対応するインテリジェントなルックアップテーブルのデータを実行するSQLを記述する必要を支援しないことができるようになります。
しかし、マルチテーブルのクエリと関連する動的SQL、SQLおよびその他のカスタム非常に非友好のためにJPA。JPAのために、実装は、実装QueryDSLであり、コードの実装は以下の通りです。私はお願いしたいと思います：あなたは、この代わりのSQLコードにそれを使用しますか？


JPAQueryFactory queryFactory = new JPAQueryFactory(em);
JPAQuery<Tuple> jpaQuery = queryFactory.select(QTCity.tCity,QTHotel.tHotel)
                                .from(QTCity.tCity)
                                .leftJoin(QTHotel.tHotel)
                                .on(QTHotel.tHotel.city.longValue().eq(QTCity.tCity.id.longValue()));
//添加查询条件
jpaQuery.where(predicate);
//拿到结果
return jpaQuery.fetch();

もう一つの方法は、NativeQueryを使用することです、私はまだお願いしたいと思います：あなたはそれを戦うための方法でSQL文字列内のJavaコードを書いてみませんか？


@Entity
@NamedNativeQueries(value={
        @NamedNativeQuery(
                name = "studentInfoById",
                query = " SELECT * FROM student_info " 
                      + " WHERE stu_id = ? ",
                resultClass = Student.class
                )
})
@Table(name="student_info")

これは、動的SQLを考慮すると、動的SQLの問題になりません上記の実現の一部であり、言葉遣いはより複雑になります。いわゆる動的SQLはこれです：異なる条件で渡されたパラメータ、異なる構成のSQLによると、2つのフレームワークを比較する多くの記事がこの点に関して、より良いサポートをMyBatisの中で、ダイナミックSQLの問題を無視してきました。MyBatisのは、JavaコードのJavaコードまたは文字列を戦うのではなく、最終的な分析のSQLでの動的SQLを記述します。いくつかのことに対して特に耐性プログラマ：

内部のJavaコードで書かれたSQLの複雑な関係、戦いの文字列の書き込みが便利ではありません
SQLは、リレーショナルクエリ言語のエンティティの最良の表現は、プログラマが疎外のSQL言語を使用したくないです。
プログラマは一般的ではない何かを学ぶにしたくない、私たちは、SQL明らかになります
オペレーティングJPAパッケージアップだけでなく、非常に良い使用していますが、SQLチューニングのほとんどは、どのように行うが？

あなたは問題JPA戦いの文字列の書き込みとSQLの疎外を解決春データ-JPA-余分に使用することができます。しかし、使い方の著者によると、春-DATA-JPA-余分な生産のための個人的なプロジェクトの開発者は、マルチソースデータ処理のための問題、治療の複雑な種類がたくさんあり、まだ未熟です。

第二に、グレシャムの法則？

しかし、思考の他の学校は、あなたはJPAとどのように他の人の海外のプログラマを参照してください？あなたが何か新しいことを学習することはありません、他の人が使用してはいけませんか？JPAは、ああ、非常に使いやすい、唯一の欠点は、SQLのサポートに伴う複雑さが近づいたですが、限り、あなたはまた、それを学ぶようあなたはグレシャムの法則何ですか、ああサポートすることができます。うまく設計された実体関連モデル後の場合は、JPAは、生成されたSQLによるSQLプログラマが本当に優れたJPAエンティティの関係を記述するために、明確に最適なソリューションです。私は、このビューが正当化される、と言いたいです。しかし、私は国内のプログラマが学びたいが、別の理由ではないんではないと言いたいです。

まず第一に、それは外国人のプログラマーとリモート、より接触して長年にわたって動作します。アプリケーションは、自分たちの国の大きさのために、本当に小さすぎるため、数百万人の移動に比べて、彼らは、アプリケーションの国内のユーザーに比べて、JPAの理由を使用することに慣れている、彼らは明らかにデータベースの設計とチューニングのニーズに、よりリラックスしています。
アプリケーションのデザインは、海外より簡潔になる傾向があり、国内のアプリケーションは、多くの場合、より多くの機能です。あなたが信じていない場合、あなたは彼らはしませんでした、行くと、私たちが発明したロールバック処理をし、どのようなものでしょうどのような作業の流れを、見ることができます。あなたは、彼らが行うことができない疲れ嘔吐、JPAでそれを試してみる私たちのワークフローアプリケーションのいずれかを書いてみましょう。
あるいは疎外内部のSQLコードは、SQLを書く学習コストとある程度のコストを増加させました。だから、少数の人々は、あなたがチームのほとんどの人々を満たすために持っている少数の人々と、使用しています。

上記の点を有する、MyBatisのは、なぜこれほど多くの国内のユーザーとメーカーが理解することは困難ではない使用があります。使いやすさの不足を補うためにMyBatisのプラスまたはコード生成：MyBatisのものような、使用されてもよいです。JPAの図は、結婚し、すべてが文字の外にある、その顔には、社会的関係を処理することは困難陳ポイントをノック見えます。MyBatisのは、優れていないすべての点で、体もまずまずの外観にすることができますが、性格も良いです。キーはあなたがしている、と彼はメイクアップ友人を助けるために喜んでいるの言うことに耳を傾けることです。あなたはどちらを選択したいと言いますか？

まあ、一部の人々は、あなたが何を再送している、と言うでしょうか？まだ外国の観客、機能的なインターネットアプリケーションの数よりも多くありませんか？私は、これは事実で、それは国内よりも多くを持っているんです。しかし、国内以上の比率から言えば、開発者の割合は、技術の方向性を選択することにしました。また、これは思考につながったが、彼らは通常、JPAの訓練を使用することを学ぶので、大規模なサービスアプリケーションを作成するときにもJPAを使用しています。まあ、それは複雑なSQL JPAはそれを書くと書くのか？答えはほとんど使用されず、さらにいくつかの外国企業は、クエリSQLに関連付けられている禁止書き込みします。それをどのように行うには？ビジネス要件を開発する方法SQLに関連付けられていませんか？ああではありません。

第三に、サービスの分割またはわずかサービス

今、そこに、より多くの国内企業は、あるドロップマイクロサービスでしたが、非常にいくつかの本当に良いビジネスフロア。関係はどのようなクエリに関連付けられているこのマルチテーブル？私たちは、最初にこのような要求を達成するために：クエリは、すべてのビジネスデータA B-関連のロールに属しています。

私たちは、伝統的な単一のアプリケーションを開発する場合、我々は表Aと表Bビジネスアソシエイトクエリの役割もして、クエリ結果を得ることができます
我々が行う場合はマイクロサービスで、我々は権限サービスA、Bのビジネスサービスに分割することができますサービス・インターフェースは、フラグ情報、役割フラグに基づいて、Bの業務データを取得するためにビジネス・サービス・インターフェースに、情報の役割に行くためのアクセスを得ることができます。

だから、何人かの人々は、二つのインタフェースへのアクセスは、それのインタフェースにアクセスするよりも低速でなければならない、と言うだろう！これは本当に、我々はマイクロサービスを行う場合、アプリケーションが特定のレベルに到達するために私たちのサイズとデータ量でなければならない、ではありません。私たちは、確かに多くのアプリケーションが開発モード、少ない機会の使用に関連したマルチテーブルクエリを分散している場合、洗練されたサービスやその他の問題を分割し、負荷分散をポイントテーブルや倉庫を検討します。分割後により単機能、負荷シャントおよびその他の理由は、アクセス速度がしばしば集中格納されたデータへのサービスは、より速く、より多くのサービスは、集中アプリケーションの展開となり、データの量よりも大きいです。

問題は、どのようにSQL開発プロセスに関連付けられていない、帰ってきましたか？全体的なサービスは、アプリケーション・インターフェース・データの組織的関係の合理的、合理的な設計により分割され、チームは良い着陸マイクロサービスの経験を持って、アプリケーションの開発に関連付けられているSQLクエリを使用することなく達成することができます。我々はすべて知っているように、NOSQLは、より多くの人気、NOSQLデータベースのほとんどは何の関係、いわゆるません。

第四に、フレーム選択の比較

比較項目	春データJPA	MyBatisの
単一テーブルの操作	ただ、連続、コードは非常にまれであり、非常に便利です。そしてキーワード生成されたSQLでメソッド名をサポート	コード生成ツールを使用したり、MyBatisの-Plusと他のツールすることができる、また、非常に便利ですが、比較的弱いJPA。
クエリに関連したマルチテーブル	一緒に結合された、非常に友好的ではない、動的SQLを使用するのに十分便利ではない、とSQLとコード	フレンドリーで非常に直感的、動的SQLを持つことができます
カスタムSQL	SQLのメモを書き、いくつかの激しいダイナミックなSQLを書くために	SQLは、動的SQL構文の武器を記述することであるXMLで記述することができます。注釈はまた、SQLをサポートしています。
学習コスト	やや高いです	下の書き込みの基本的なSQLを使用します。

ビューの著者のポイントをまとめると：

あなたは、自己開発している場合、あなたがJPAを使用することが推奨され、アプリケーションの「スモールイズビューティフル」
あなたが大規模とエンタープライズアプリケーションの開発者であれば、もちろん、技術の選択は、チームに従ってください。国の技術の選択は、通常、MyBatisのです。
あなたの会社の経営は非常に標準であれば、マイクロ着陸サービスの経験は非常に成熟して、チームプロジェクトでJPAを使用することを検討してください。ほとんど、あるいはまったく関連するクエリを持ちます。

あなたの注意を楽しみにして
ブロガーは最近、本を書いた：「手のタッチ手をSpringBootシリーズ章97節を学ぶためにあなたを教えるために-16」
：この記事は、ソース（エンはテキストのみをオンにしてはいけません）を示して再現された文字ジボオフ。