私の開発者は内戦を繰り広げています。ある陣営では、Hibernate と Spring を採用しました。もう一方の陣営では、彼らはフレームワークを非難しましたが、Hibernate を検討しています。
問題は、初心者の Hibernate-Spring への変換者が遭遇する可能性が高い厄介な驚き、弱点、または落とし穴はありますか?
PS: あまり洗練されていない DAO ライブラリがあります。それが Hibernate のリッチさを持っているとは思えませんが、ある種の成熟度に達しています (つまり、含まれている最近のいくつかのプロジェクトでは変更されていません)。
彼らはフレームワークを非難しましたか？
それはナッツです。既製のフレームワークを使用しない場合は、独自のフレームワークを作成します。それはまだフレームワークです。
過去に何度もHibernateを使用しました。構文を決定することが、ドキュメンテーション、Google、および古いバージョンのスカベンジャー ハントに発展するエッジ ケースに遭遇するたびに。これは強力なツールですが、文書化が不十分です (最後に調べました)。
Spring に関して言えば、過去数年間に私がインタビューしたり調べたりしたほぼすべての仕事に Spring が関係しており、Spring は Java/Web の事実上の標準になっています。それを使用することで、開発者は将来的に市場性を高めることができます。また、アプリケーションを理解する大勢の人々を獲得できるので、あなたにも役立ちます。
独自のフレームワークを作成することは、魅力的で、教育的で、楽しいものです。結果はそれほど良くありません。
Hibernateには確かに癖がありますが、それは解決しようとしている問題が複雑だからです。誰かがHibernateについて不平を言うたびに、私は、彼らがそれを使用していなかった場合に維持しなければならない退屈なDAOコードのすべてを思い出させます。
いくつかのヒント：
これは、私が休止状態の時代に陥ったことの1つです（覚えていました）。（親エンティティ内の）コレクションから（いくつかの）子オブジェクトを削除し、途中でフラッシュせずに1つのトランザクションで同じコレクションに新しいエンティティを追加すると、Hibernateは「削除」の前に「挿入」を実行します。子テーブルの列の1つに一意の制約があり、以前に（私と同じように）すでにいくつかのデータを削除しているため、違反しないと期待している場合は、イライラする準備をしてください。Hibernateフォーラムは次のことを提案しています。
両方を行うことはできず、Hibernateソースを微調整して再コンパイルすることになります。たった1行のコードでした。しかし、1つのラインを見つけるための努力は、約27杯のコーヒーと3つの眠れない夜に相当しました。
これは、チームに実際の専門家がいない状態でHibernateを使用するときに発生する可能性のある問題と癖のほんの一例です（専門家：Hibernateの哲学と内部作業について十分な知識を持っている人）。あなたの問題、解決策、コーヒーのリットル、そして眠れない夜の数は変わるかもしれません。しかし、あなたはその考えを理解します。
遅延読み込みは、永続化フレームワークにHibernateを使用するMVCアプリケーションの大きな落とし穴です。コントローラにオブジェクトをロードし、それをJSPビューに渡します。コントローラが完了したときにHibernateセッションが閉じられたため、クラスのメンバーの一部またはすべてがプロキシされ、すべてが爆発します。
問題を理解して解決策を得るには、 Open SessioninViewの記事を読む必要があります。Springを使用している場合、このブログ記事では、オープンセッションのビューの問題に対するSpringソリューションについて説明しています。
かなり複雑なデータベースを使用している場合、Hibernate は適していない可能性があります。職場では、大量のデータを含むかなり複雑なデータベースがあり、Hibernate は実際には機能しません。代わりに iBATIS の使用を開始しました。しかし、私は Hibernate をうまく使っている多くの開発ショップを知っています。
適切に使用する方法を知っていれば、Spring は優れたツールです。
フレームワークは間違いなく良いことだと思います-他の人が指摘したように、車輪を再発明したくない. Spring には多くのモジュールが含まれているため、それほど多くのコードを記述する必要はありません。「Not Invented Here」症候群に屈するな！
私はいつもHibernateが少し複雑で、学ぶのが難しいことに気づきました。しかし、JPA（Java Persistence API）とEJB（Enterprise Java Beans）3.0はしばらくの間存在していたので、物事はずっと簡単になりました。JavaDocまたはXMLを介してマッピングを作成するためにクラスに注釈を付けることを強く好みます。Hibernateのサポートを確認してください。追加のボーナスは、必要に応じて後でデータベースフレームワークを変更できることです（ただし、簡単ではありません）。私はOpenJPAを使用して素晴らしい結果を出しました。
最近、私はますますJCR （Javaコンテンツリポジトリ）を使用しています。モジュールが単一のデータストレージを共有できる方法と、構造とプロパティを進化させる方法が大好きです。オブジェクトをデータベースにマッピングするよりも、ノードとプロパティを操作する方がはるかに簡単だと思います。良い実装はJackrabbitです。
Springに関しては、私が気に入っている機能がたくさんありますが、構成に必要なXMLの量は、私がそれを使用しないことを意味します。代わりに、 Guiceを利用して、絶対に気に入っています。
まとめると、疑わしい開発者に、Hibernateがどのように彼らの生活を楽にするかを示します。Springに関しては、Guiceが実行可能な代替手段であるかどうかを真剣に確認してから、Spring/Guiceが開発をより良く簡単にする方法を示します。
私は Java をあまり扱ったことがありませんが、Java 開発者の大規模なグループで働いたことはあります。春はいいなという印象でした。しかし、誰もが Hibernate に腹を立てていました。チームの半数に「1 つ変更できるとしたら、何を変更しますか?」と尋ねられた場合。彼らは「休止状態を取り除け」と言うでしょう。Hibernate を学び始めたとき、驚くほど複雑であることに気づきましたが、その複雑さが正当化されるかどうか (複雑な問題を解決するために必要だったのかもしれません) を知るのに十分ではありませんでした (ありがたいことに、私は先に進みました)。
チームは Spring を廃止して Guice を採用しましたが、少なくとも私と私が話をした他の開発者の観点からは、それはむしろ政治的な変化のようでした。
私はSpring/Hibernateの開発をたくさん行いました。時間の経過とともに、人々が両方を組み合わせて使用する方法は少し変わりました。元のHibernateTemplateアプローチは、他の点では有用な例外を飲み込んでラップするため、デバッグが難しいことが証明されています。Hiberante APIに直接話しかけてください！
生成されたSQLを引き続き確認してください（SQLを表示するように開発ログを構成します）。データベースに抽象化レイヤーがあるからといって、SQLで考える必要がなくなったわけではありません。そうしないと、良いパフォーマンスが得られません。
プロジェクトを検討してください。厳しいパフォーマンス要件、複雑なレガシースキーマ、または優れたSQLを記述できる優れたDBaがあった場合、HibernateではなくiBatisを選択しました。
Hibernateに関しては、急速に変化するデータベーススキーマ、大量のテーブルを処理するアプリケーションに非常に優れたツールであり、多くの単純なCRUD操作を実行します。複雑なクエリが含まれるレポートは、あまり適切に処理されません。しかし、これらの場合、私はJDBCまたはネイティブクエリを混合することを好みます。つまり、簡単に言えば、Hibernateの学習に費やした時間は良い投資だと思います（EJB3.0およびJPA標準にも準拠していると言われていますが、個人的に評価したところ、それは方程式に含まれていませんでした。使用する）。
春については...胆汁ブログを参照してください:)
覚えておいてください：フレームワークは特効薬ではありませんが、車輪の再発明もすべきではありません。
SpringとHibernateは、習得するのが難しいフレームワークです。フレームワークを理解しようとしているときに、締め切りが厳しいプロジェクトでそれらを使用するのは良い考えではないかもしれません。
フレームワークの利点は、基本的に、一貫性のあるコードを製品にするためのプラットフォームを提供しようとすることです。経験から、開発者にフレームワークの設定のベストプラクティスを経験してもらうことをお勧めします。
アプリケーションやデータベースの設計によっては、フレームワークがパフォーマンスを妨げないようにするために回避する必要のある癖もあります。
これに関する多くの投稿に同意する必要があります。私はさまざまな設定で両方を広範囲に使用しました。設計上の決定を元に戻すことができるとしたら、それは Hibernate を使用することでした。私たちは実際に、Hibernate を iBatis に、Spring-JDBC を世界最高のアプローチに置き換えるために、製品の 1 つのリリースの予算を立てました。新しい開発者に、Spring-JDBC、Spring-MVC、Spring-Ioc、および iBatis を使用して、Hibernate を任せた場合よりも早く習得してもらうことができます。
Hibernate は、この KISS 開発者にとって複雑すぎます。そして、DBA が生成された SQL をデータベースが認識し、最適化されたバージョンで送り返すことを DBA が認識した場合、休止状態をサポートしてくれます。
一番上の回答は、Hibernate の文書化が不十分であることを示しています。私は、オンライン リファレンス マニュアルがより完全であることに同意します。しかし、Hibernate の著者によって書かれた本「Java persistence with Hibernate」は、すべての Hibernate ユーザーにとって必読であり、非常に充実しています。
私の意見では、Spring の最大の利点は、より良い開発プラクティス、特に疎結合、テスト、およびより多くのインターフェースを奨励し、可能にすることです。Spring を使用しない Hibernate は非常に苦痛ですが、この 2 つを一緒に使用すると非常に便利です。
既存のプロジェクトをフレームワークに改造するのは骨の折れる作業ですが、リファクタリング プロセスは長期的な保守性に大きなメリットをもたらすことがよくあります。
Hibernate などのよく知られたフレームワークを使用すると、コードが特定の型や考え方に適合するため、非常に役立ちます。つまり、Hibernate を使用しているので、特定の方法でコードを記述し、Hibernate を知っているすべての開発者ではないにしてもほとんどの開発者が、あなたの考え方に非常に簡単に従うことができます。
もちろん、これには欠点があります。熱心な Hibernate 開発者になる前に、正方形を円形の穴に合わせようとしていることに気付くでしょう。あなたは自分が何をしたいのか、そして Hibernate が登場する前はどのようにそれを行うべきだったのかを知っていますが、それを行う Hibernate の方法を見つけるにはかなりの時間がかかるかもしれません.
それでも、コンサルタントを頻繁に雇う企業 (短期間に大量のソース コードを理解する必要がある企業) や、開発者が頻繁にサインオンして辞める企業、または主要な開発者が永遠に留まり、仕事を変えることはありません。Hibernate やその他の標準フレームワークはかなり良いアイデアだと思います。
/エース
フレームワークは悪ではありません。JavaSDKでさえフレームワークです。
彼らがおそらく戦うのはフレームワークの拡散です。プロジェクトを開始するためだけにフレームワークをプロジェクトに導入するのではなく、妥当な時間内に一貫した価値をもたらす必要があります。すべてのフレームワークには学習曲線が必要ですが、後で生産性と機能が向上することで報われるはずです。
一貫性のないデータベースの使用、複雑なキャッシュメカニズム、またはその他の無数の理由のためにデバッグが難しいコードで苦労している場合。Hibernateは大きな価値を追加します。学習曲線（私にとっては約1か月の実践的な作業が必要でした）を除けば、基本を説明してくれる人がいれば、落とし穴はありませんでした。
@slim-私は今朝またあなたと一緒にいます。
Not InventedHereSyndromeの典型的なケースのように聞こえます。彼らが春に熱心でないなら、彼らは彼ら自身のフレームワークを転がすのではなく、他のオプションを検討するべきです（彼らがそれをすることを認めるかどうかにかかわらず）。 可能性としてGuiceが思い浮かびます。また、picocontainer。必要なものに応じて、他にもあります。
SpringとHibernateは間違いなく生活を楽にします。それらを使い始めるのは最初は少し時間がかかるかもしれませんが、後でそれから確かに恩恵を受けるでしょう。現在、XMLは注釈に置き換えられているため、数百行のXMLを入力する必要もありません。
AppFuseを検討して、学習曲線を減らすことをお勧めします。アプリケーションを生成し、それを研究して適応させれば、すぐに利用できます。