のn層アプリケーション

Question

私が主な目的は、データベースからデータを取得UIに表示、ユーザー入力に取り、戻ってデータベースにそれらを書くことで、Webベースのアプリケーションを開発していますに階層の数を決めます。このアプリケーションは、どんな工業的強度のアルゴリズムのクランチングもやっていないでしょうが、ピーク時（以下に記載）に非常に多くのヒットを受け、その日に変化します。

プレゼンテーション、ビジネス、データデータレイヤーは、データベースサーバーによって処理されます。ビジネス層には、tcpを介してデータベースサーバーにアクセスするためのDALコンポーネントが含まれます。私は階層に、これらの層を分離しなければならない選択肢は次のとおりです。

1. プレゼンテーションとビジネス層は同じか 層に保つことができます。

2. 単独で別の層のプレゼンテーション層とそれ自身で別の層の 層を表示します。

選択肢2の場合、ビジネスレイヤーは、httpまたはtcp上のWCFサービスを使用してプレゼンテーションレイヤーによってアクセスされます。

私は、ビジネス層の上に行われている任意の重い処理が表示されていないので、私はオプション上記1に傾いています。私はまた、新しい層を追加すると同じ理由で、ネットワーク遅延を導入するだけで感じる。しかし、スケールアップが必要な場合やスケーラビリティの観点から、どちらの方が良い方法ですか？このアプリケーションでは、1時間に最大600万人のユーザーをサポートできる必要があります。各ユーザセッションには、ユーザの嗜好やその他の詳細を格納する妥当な量のデータが存在する。私は、単純なCRUD Webアプリケーションについて話すとき、私は本当に長期的「n層アーキテクチャ」を好きではありません... ..だけでなく

Answer 1

のお時間を

感謝をページ・レベルのキャッシュを使用することになります。 MVCのようなデザインパターンを選んで、それに行きましょう。すべての層については忘れてください。

アプリケーションは、個々の成分を別々にスケーリングを心配するのに十分な大きさや十分な人気になるだろうされていません。おそらく、あなたのアプリケーションは単一のVSソリューション（そして場合によってはプロジェクト内の単一のアプリケーション）になります。私が言ったことのほうが少し意味があるようであれば、私はお詫びしますが、私は同じバケツに構築したすべてのものを数えます。また、あなたの特定のプロジェクトで私が言ったことが全く間違っている場合、私は再び謝罪し、控えめにdownvotesを受け入れます。これはあなたがこれを考え過ぎているように本当に響きます。それを構築し、参照してください。

あなたは、入力、表示、およびデータアクセスのウェブサイトを構築しています。新しいASP.NET MVCソリューションを起動し、町に行く。