2

MVC3/.Netアプリケーションのデータベースアクセスを処理するクラスを見ています。

このクラスは静的であり、一般的なDBクエリ（「GetColumnBValueForColumnA（）」などのあらゆる種類の厄介なものや、はるかに複雑なクエリ）に便利なメソッドを提供します。これは、特定のソリューションとドメインに対して適切に因数分解/最適化されています。

ただし、クラスを静的であると見なすと、これがどのように悪い考えであるか（おそらくマルチスレッドのコンテキストでは？）について、半分忘れられた記憶が引き起こされ、私はその気持ちを揺るがすことができません。

この種のクラスを静的に保つのは良い考えですか、それともデータベース呼び出しごとにインスタンス化する必要がありますか？

4

2 に答える 2

5

この種のクラスを静的に保つのは良い考えですか、それともデータベース呼び出しごとにインスタンス化する必要がありますか？

アプリケーションのレイヤー間の弱い結合、それらのレイヤーの再利用性、単体テストなどを気にする場合は、上記のいずれも実行しないでください。抽象化を使用する必要があります。

これらのことを気にしないのであれば、静的メソッドで十分です。静的メソッドを使用する際に注意する必要があるのは、スレッドセーフにするために、再入可能で共有状態に依存しないように設計することだけです。すべての場合において、データベース接続やコマンドなどのすべてのIDisposableリソースを、usingステートメントでラップして適切に破棄するようにしてください。

于 2012-01-23T21:22:32.750 に答える
2

この種のクラスを静的に保つのは良い考えですか、それともデータベース呼び出しごとにインスタンス化する必要がありますか？

これらはあなたの2つの選択肢だけではありません。

クラスは静的であってはなりません。静的にすることで、オブジェクト指向プログラミングのいくつかの重要な利点を放棄し、実質的に何も得られません。

代わりに、そのインスタンスをコンストラクターベースの依存性注入を介してコントローラーに提供する必要があります。クラスがリクエストごとに再インスタンス化されるかどうか、またはシングルトンを使用するかどうかは、DIバインディングコードによって決定されます。帽子をかぶるだけで交換できます。

ここにいくつかの利点があります：

  1. このデータアクセスクラスに依存するメソッドを単体テストするとします。静的メソッドを直接呼び出すのではなく、挿入されたサービスインターフェイスを使用している場合は、モックオブジェクトを作成し、その動作方法を指示して、単体テストを行っているメソッドが実際にデータを取得していると見なせるようにすることができます。テストしたいデータをフィードするだけです。
  2. データアクセス呼び出しの結果をキャッシュしたいとします。実際のクラスをラップするキャッシングクラスを挿入し、可能な場合はキャッシュされた結果を返し、キャッシュされた値が存在しない場合は実際のデータアクセスメソッドを呼び出すことができます。これには、データアクセスクラスを変更する必要はありません。

私は続けることができました。静的クラスは柔軟性を損ない、99％の確率で実用的な利点はありません。

于 2012-01-23T21:25:32.427 に答える