データベース接続をライブラリに渡す
Java library（jar file）を作成して、社内アプリケーションのデータベースにWebサービスの要求と応答を記録します。このライブラリには2つのメソッドregisterReuqestとregisterResponseがあります。
私は疑問に思っていますこれらのライブラリメソッドにデータベース接続を渡すのは良い考えですか？
ライブラリへの接続の受け渡しには、いくつかの長所と短所があります。
長所： 1つの接続を使用して、要求と応答の両方を登録できます。これにより、2番目の接続を開く際の遅延が減少します。場合によっては、発信者サービスも同じ接続を使用します。
短所：発信者サービスとライブラリが結合されます。
これらのライブラリメソッドにデータベース接続を渡すのは良い考えですか？
反対の質問：しない接続を渡す場合、ライブラリはデータベースへの接続をどのように開きますかそれ自体？
どれデータベース？
どのように構成されていますか？
どこで構成されていますか？
これらがライブラリに心配させたくないものである場合は、使用する接続をライブラリに渡します。
質問のIoCタグから判断すると、ある種の制御の反転コンテナを使用していると思います。そのため、質問に答えるには、いいえアプリケーションにデータベース接続を直接渡してはなりません。図書館。
代わりに、依存性注入を利用する必要があります。データベース接続を必要とするソフトウェアコンポーネントは、IoCコンテナによって構築/初期化する必要があります。これにより、ソフトウェアコンポーネントに必要な依存関係が注入されます。
データベース接続の競合に関する懸念については、これはデータベース接続プールを利用することで十分に解決された問題です。データベース接続を要求する代わりに、ソフトウェアコンポーネントが接続を要求できるデータベース接続プールを要求し、完了したらプールに戻ります。これにより、ライブラリを使用するアプリケーションは、プールの詳細を構成し、ニーズに合わせて最適化できます。この時点で心配することはあなたの問題ではないでしょう。
呼び出し元のアプリケーションはライブラリに何かを渡す必要がありますが、通常、これらはライブラリによって内部的に使用される接続をインスタンス化するために必要なプロパティまたは構成ですが、実際の接続自体ではありません。ライブラリは構成を取得して接続を作成し、その存続期間を管理します。接続は公開しないでください。
一般的な構成は、次のようなプロパティになります。
- サーバーネーム
- ポート
- データベースインスタンス
- ID /パスワード
アプリケーションは、接続してそれらのライブラリを渡す必要があるデータベースを認識しているため、接続プロパティを独自の構成ファイルに保存します。
あなたの場合、ライブラリは必要に応じて要求/応答呼び出しの接続の存続期間を内部的に管理できます。