4

まず、いくつかの背景。私たちは最近、大規模な MVC3 プロジェクトを引き受けました。プロジェクトはかなり前に公開する準備ができていましたが、クライアントは、Web サイト全体のテーマを変更し、より多くの機能を追加することを決定しました。彼らは、サイトのテーマを変更し、残りの機能を完成させて展開するために私たちを雇いました.

通常、データベース テーブルごとに 1 つのリポジトリと明確なサービス レイヤーを使用して、非常に明確で順序付けられたアプローチを使用して構築されますが、少し不快に感じる奇妙な点がいくつかあります。私を悩ませ続けている主な奇妙な点は、アプリケーション内のすべてのリポジトリとサービスが完全に 100% 静的であることです (そうです、db に書き込むメソッドを含みます)。もちろん、これでは単体テストはできませんが、より大きな懸念事項は、アプリケーションに大きな負荷がかかったときに発生する潜在的なボトルネックとスレッドの問題です。ステージ サーバーでリクエストを処理する際に、説明のつかない遅延が発生しています。

アプリケーションは非常に巨大であるため、IOC/リクエストごとにインスタンス化されたリポジトリを使用するように再構築することはほとんど問題になりません。

展開時に潜在的なスレッド化の問題を回避するにはどうすればよいですか? 接続プールを使用して、書き込みが必要になるたびにデータベース接続を借りることはできますか?

前もって感謝します ：）

編集 - エンティティ モデルのインスタンスを作成するコードの一部を次に示します。各静的メソッドは、この「DemoEntities」メソッドを呼び出してエンティティ モデルのインスタンスを取得し、それを使用して db コマンドを実行します。メソッドは静的ですが、実際には HttpRequest で既存のインスタンスをチェックし、存在しない場合はインスタンスを作成していることがわかります。そういうわけで、私たちは大丈夫だと思います。

   public static DemoEntities DemoEntities
   {
       get
       { 
           if (HttpContext.Current != null && HttpContext.Current.Items["DemoEntities"] == null) 
           {
               HttpContext.Current.Items["DemoEntities"] = new DemoEntities(); 
           }
           return HttpContext.Current.Items["DemoEntities"] as DemoEntities;
       }
       set
       {
           if (HttpContext.Current != null)
               HttpContext.Current.Items["DemoEntities"] = value;
       }
   }

`

パット

4

1 に答える 1

6

ここでは、リポジトリ クラスには静的メソッドのみが含まれており、静的状態は含まれていないと仮定します。

ステートレスな静的クラスの利点は、デフォルトのパラメーターなしのコンストラクターを使用して安全に通常のクラスに変換でき、寿命を気にする必要がないことです。次に、テスト目的でインターフェイスを抽出するのは簡単なケースです。

リポジトリと対話する必要があるときはいつでも、インスタンス化するだけです。

リポジトリの使用中にアプリケーションが共有状態で何かを行っていない限り、マルチスレッド アクセスについて心配する必要はありません。データベース自体が、多数の同時呼び出しを処理します。

現在、すべてのボトルネックとスレッドの問題は潜在的なものであり、何が問題になる可能性があるかについての私たちの経験に基づいた推測自体が間違っている場合があります。特にマルチスレッドではそうです。速度が低下するのは、データベースがあまりにも多くの要求に対処するための機能を備えていないためかもしれません。

于 2012-06-06T15:05:18.163 に答える