私のプログラムの一部として、 ( ) データベースJavaに対して多くのクエリを実行する必要があります。Oracle
現在、私たちは SQL と Java を組み合わせて作成していますが、これは (私は知っています) 悪い悪いことです。
このようなものを処理する正しい方法は何ですか? 可能であれば、例を含めてください。
ありがとうございました。
編集：
アプリケーションに関するもう少しの情報。これは、主にデータベースからコンテンツを取得する Web アプリケーションです (ユーザー入力を受け取り、データベースが正しいと信じている内容に基づいて、次に表示されるコンテンツを描画します)。
現在のやり方で私が抱えている最大の懸念は、Java コードと SQL クエリを混在させると、これほど緊密に結合すると「場違い」に見えることです (ソース コードの一部としてハードコードされたクエリ)。
この状況を処理するためのよりクリーンな方法を探しています。これにより、目前のプロジェクトの保守性と明確さが向上します
あなたが説明したように、オブジェクト リレーショナル マッパー (ORM) を組み込んだり、ストアド プロシージャとして書き直したりすることは、おそらくあなたが受け入れたいと思う以上の作業です。どちらも重要な学習曲線を持っています。
代わりに、テーブルまたは目的ごとに SQL をクラスに統合することをお勧めします。テーブル データ ゲートウェイ オブジェクトとデータ アクセス オブジェクトの設計パターンを見て、これが実際にどのように行われるかを確認してください。
このアプローチの結果は無数にあります。クエリが 1 か所にあるため、再利用の可能性が高くなります。JDBC と SQL のいくつかの行をメソッド呼び出し (例: userTableDataGateway.getContentToShow(pageId)) に置き換えると、クライアント コードが読みやすくなります。最後に、これは ORM が解決に役立つ問題をより明確に理解するのに役立ちます。
さて、検討できることの 1 つは、オブジェクト リレーショナル マッパー(たとえば、Hibernate ) です。これにより、データベース スキーマを Java オブジェクトにマップできるようになり、通常は Java コードがクリーンアップされます。
ただし、パフォーマンスと速度が重要な場合は、プレーンな JDBC ドライバーを使用する方がよい場合があります。
もちろん、これはアプリケーションが達成しようとしているタスクにも依存します。たとえば、CSV ファイルに基づいてバッチ更新を行う必要がある場合は、純粋な JDBC ソリューションを使用できます。Web アプリケーションを設計している場合は、間違いなくORM ソリューションを使用します。
また、純粋な JDBC ソリューションでは、Java コードに SQL を含める必要があることに注意してください。実際には、 ORM ソリューションでも、 HQL、JPQL、またはプレーン SQL など、何らかの形式の SQL が必要になります。つまり、Java アプリケーションの一部の SQL に問題はありません。
OPの編集に応じて編集する
Web アプリケーションをゼロから作成する場合は、ORM を使用します。ただし、すでにアプリケーションが動作しているため、純粋な JDBC ソリューションから ORM に移行するのは非常に困難です。コードをクリーンアップできますが、かなりの学習曲線が必要であり、かなりのセットアップが必要です。Spring のようなある種の Bean 管理システムを使用している場合は、セットアップの手間がいくらか軽減されますが、それでもかなり重要です。
また、アプリケーションでどこに行きたいかによっても異なります。かなりの期間、このコードを維持および追加する予定がある場合は、リファクタリングが適切である可能性があります。ただし、アプリケーションに SQL をハードコーディングしたくないという理由だけで、システムを書き直すことはお勧めしません。
プロジェクトの状態はわかりませんが、MyBatis という「代替」オブジェクト リレーショナル マッパーを見つけることもできるかもしれません。人気のある hibernate や eclipselink よりも学習曲線が低く、実際にクエリを記述できるので、コードが何をしているかがわかります。それは、ORMがあなたのものである場合です。
私は現在 JPA を使用しています (主にそれが現在の傾向であり、学習する必要があるため)。JPA は ORM の Java 標準です。現在の典型的な ORM の方法を学びたい場合は、おそらく JPA が最適な方法です。Hibernate や Eclipselink などのフレームワークがそれを推進します。JPA アプリの基盤として選択したフレームワークに応じて、独自の機能を使用できますが、そのフレームワークに完全に結び付くことになります。JPA の使用を開始するのは難しくありませんが、データベースとの対話をかなり難読化するため、機能しない場合は非常に不可解になる可能性があります (注意してください、ネイティブ SQL クエリを使用するオプションを許可しますが、そのようなものは無効になります) JPA スタイルの DB アクセスが良いと人々が言う理由)。
はい、準備済みステートメントで JDBC を使用している人はまだいます。そして通常、プレーンな古い JDBC でプログラミングするときに使用するプラクティス/パターンがあります。これは、非常に最小限の ORM のように動作します...または実際には、MyBatis に近いものです。繰り返しますが、この方法を使用する場合は、準備済みステートメントを使用してください。彼らは多くの危険を否定します。
これは宗教的な種類の質問なので、あなたが質問を書いた方法で多くの改宗を耳にするでしょう. 実際、誰かがあなたの質問を否定するかもしれません。もっと悪いかもしれないとあなたが尋ねることができる唯一のことは、emacsとviのどちらが多くのUNIXオタクにとって優れているかということだと思います.
あなたの最新情報に基づいて、Tim Pote の編集 re: the learning curve to integration ORM に同意します。ただし、ORM を統合する代わりに、準備済みステートメントを使用して、プロパティ ファイルに格納するなどの操作を行うこともできます。または、DB にクエリを保存して、アプリ サーバーを再起動せずにクエリをすぐに読み込むことができるように、クエリに微妙な更新を加えることもできます。これらの戦略は両方とも、ハードコーディングされた SQL の Java コードを整理します。
結局のところ、あなたの質問に対する明確な答えはないと思います。少し柔軟性がありませんが、状況によっては許容範囲内です。
そうは言っても、私はこれを答えとして投稿しています！
あなたの質問は一般的すぎるようですが、Oracle と Java SQL の Direct SQL が混在している場合は、Hibernate や Apache Cayenne などの ORM に時間を投資することをお勧めします。ORM は、Java 側からデータベース操作を分離するための個別の設計アプローチです。すべてのデータベース インタラクションと DB 設計は ORM に実装され、すべてのアクセスとビジネス ロジックは Java に存在します。これは提案です。ただし、実際の問題についてはまだ不明です。
現在のやり方で私が抱えている最大の懸念は、Java コードと SQL クエリを混在させると、これほど緊密に結合すると「場違い」に見えることです (ソース コードの一部としてハードコードされたクエリ)。
あなたのこの仮定は、あなたの質問に対する真/偽の答えがあるという意味で、実際には「正しく」ありません。This question here は、Java と SQL の混合に対処する方法がいくつかあることを説明しています。
Java プログラミング - SQL ステートメントはどこに保存する必要がありますか?
基本的に、SQL を次のように区別します。
それに追加します：
Apache Cayenne は、最も使いやすい ORM の 1 つです。データ オブジェクトをモデル化するためのカイエン モデラーが付属しており、マッピングを行います。ORM の初心者には Cayenne をお勧めします。モデラーを介してマッピング クラスと DB 同期を作成できます。