0

私たち(私のチームと私)には、多くのユーザー(少なくとも15,000人のユーザー!)を扱う大きなWebプロジェクトがあります。精緻化フェーズでは、MVCスタイルでコーディングすることにしました。私たちはトレードオフに直面します(このプロジェクトでは、すべてのアクションは認証されたユーザーによって実行される必要があります)。

設計の1つの方法は、コントローラーが要求を取得し、それに応じて要求の責任オブジェクトを作成(DBからロード)し、そのオブジェクトの参照がコントローラーに保存され、最後にコントローラーが次のセッションに追加されることです。ユーザー。このスタイルでは、コントローラーが、頻繁に発生する可能性のあるユーザーのアクションの中で複数の動作を行う、粗い詳細なクラスである必要があります。

設計の他の方法は次のとおりです。コントローラーはリクエストを取得し、リクエストの責任オブジェクトを作成しますが、このコントローラーはステートレスであり、たとえばWebサイトの1ページに従って特定の動作をします。このようにして、ページごとにコントローラーを作成する必要があります。一部のページで共通の情報が必要な場合は、DBまたはそのキャッシュからそれらをロードする必要があります。

  • 最初のスタイルでは、作成とガベージコレクションが減少するため、コントローラーは粗い粒度のオブジェクトである必要があります。したがって、ユーザーが認証されてから1回だけ作成され、セッションが期限切れになるまでガベージになりません。セッションに存在するオブジェクトのライフサイクルは、セッションが期限切れになるまでなので、メモリ不足の原因になる可能性があると思います。
  • 2番目のスタイルでは、ユーザーが他のページに移行するたびに1つのコントローラーを作成し、DBから情報を抽出する必要があります。これにより、パフォーマンスの問題が発生する可能性があります。

私のリクエスト:メモリ使用量とパフォーマンスの2つの側面でそれらを比較したいと思います!そして、何か提案があれば、私はそれについて言及したいと思います!

簡単な例については、以下の写真を参照してください。

http://v1.iimmgg.com/images/is7gr/fb0f6b763eea5294815dcb2d50a12f56.png

4

3 に答える 3

0

オブジェクトはセッション全体で維持されるため、実際には多くのコントローラーでサイトを分割しても、DBアクセスの観点からは違いはありません。多くのコントローラーでサイトを分割することは、セッションを分割することを意味するわけではありません。

于 2011-04-25T06:08:43.370 に答える
0

私の経験則は、REST の原則に従うことです

すべてのビジネス エンティティはリソースです。リソースにはコントローラーが必要です。

電子メール、お金などの価値のあるオブジェクトはリソースではありません。

いくつかのケースでは、コントローラーを追加すると単純さが複雑さを上回り、エンティティーが直接関連している場合は、コントローラーをマージする必要があります。

于 2011-04-26T11:51:26.413 に答える
0

ほとんどの場合、データ アクセス レイヤーがシステムのパフォーマンスを決定し、mvc アプリケーションのコントローラーのサイズの影響はほとんどありません。設計の観点から、論理的に関連するアクションを 1 つのコントローラーに保持して、多数の小さなコントローラーを使用できるようにすることをお勧めします。パフォーマンスの観点から、データベースへのアクセスに焦点を当て、それが属する最適化を見つける必要があります。

于 2011-04-25T19:14:34.883 に答える