私は通常、データベース接続を自分で作成し、 `using {} 'を使って手動で寿命を制御したいと思っています。例：データベース接続をビジネスオブジェクトにカプセル化するかどうかを指定しますか？
この方法では、適切にクリーンアップする必要のあるリソースを使用していることがわかります。しかし、これは多くの反復的な努力に終わります。私は、ビジネスオブジェクト内でSQL接続を作成し、その上にIDisposableを実装したいと思っています。 Dispose（）メソッドで接続を閉じます。
using(BusinessObject myBusinessObject = new BusinessObject()) {
// do stuff with myBusinessObject
...
}
問題は、使用中に表示されない限り、ビジネスオブジェクトを廃棄する必要があることが明白でないことがあるということです。
あなたはどうしますか？
ビジネスオブジェクトは、データベースに対して合理的（または完全に）ダムにする必要があります。ビジネスオブジェクトをデータベースに保持する方法を知っているアクセスレイヤーオブジェクト（リポジトリーまたはデータコンテキスト）を実装し、それぞれのビジネスオブジェクトにコードを置くのではなく、接続ロジックを保持する必要があります。あなたのリポジトリまたはコンテキストは、それ自体の後にクリーンアップできるように使い捨てになります。あなたが作業単位パターンに従うという@ Marcの提案は良いものです。
LINQtoSQL、nHibernate、Subsonicなどを使用して、または自分で作成することを主張する場合は、良いデータレイヤーを構築する方法について、少なくともアイデアを参考にしてください。個人的な経験から、私は、既存のテクノロジーを使用することは自分自身を作成して維持するよりはるかに簡単であることを伝えることができます。
まず、リポジトリへの接続を残しておきます。
第2に、私はオブジェクトにぶら下がっている接続を維持しません。作業単位（つまり、単一のメソッド）にしか使用しません。チャンスは、（プーリングのために）とにかく同じ物理的な接続を取り戻すということです。システムはすでに、あなたがそうする必要がないように、そのようなものを扱うために長い道のりを歩んでいます。
場合によっては、トランザクションがあります。TransactionScopeは、db-transactionオブジェクトを渡すよりもずっと簡単です。
私は接続を維持することに同意します。手動で作成した接続を使用する場合と同じように、ビジネスオブジェクトの存続期間を維持します。問題は、APIを使用する他の人がそうでないかもしれないということです。おそらく、BOへの呼び出しで接続を作成/閉じることができますか？しかし、多分私たちはトランスをしたいと思うかもしれません。後で。 – dnewcome
@Marc - LINQToSQLのほうがよいかもしれませんが、私はTransactionScopeで驚異的な経験をしています。とにかくTableAdaptersを使用していると、ほぼすべてのトランザクションが分散トランザクションに昇格され、ファイアウォールを介してDBに作用する問題が終わっていないことがわかります。 – tvanfosson
@tvanfosson - 良いフィードバック;彼らが言うように：YMMV; - p –
ビジネスオブジェクトは、永続的であるかどうかを知っていても気にしなくてはなりません。個々の永続ビジネス・オブジェクトは、それがより大きい作業単位の一部であるかどうかを知ることができません。これがサービス層の責任です。接続をビジネスオブジェクトの外にしておきます。サービス層は、接続プールから通常は接続を獲得し、トランザクション境界を設定し、コミットまたはロールバックし、クリーンアップするのに適した場所です。
答えをありがとう。私がここで考えているコードはかなり簡単です。私は過去にNHibernateを使用しましたが、私はこのプロジェクトのためにそこに行きたいとは思っていません。しかし、あなたが言ったように、おそらくソースを介してスピンが良い運動になるだろう。 – dnewcome
nHibernateが多すぎると思われる場合は、LINQtoSQLを検討してください。私の経験では非常に軽量です。L2SエンティティをDTOとみなすか、部分的なクラス/メソッドを使用してそれらを本格的なビジネスオブジェクトに拡張することができます。 – tvanfosson