ソフトウェア アーキテクチャの観点から。用語は何かを意味するため、用語を使用します。「3 層」などの用語を使用する場合は、その意図と理解に適した場所で使用する必要があります。あらゆる種類のものは、何らかの種類の個別のコンポーネントが 3 つあるという理由だけで、「3 層」と見なすことができます。しかし、MVP を説明するためにその用語を使用すると、相手を誤解させることになります。簡単に「MVP」と言わないのはなぜですか?
3 層とは、一般に 3 つの物理層を指します。ウィキペディアには、ここに素晴らしい記事があります。
関連するダイアグラム:
MVP も MVC も、これら 3 つの物理層の使用を排除していません。実際、単にアプリケーションを「MVC」アプリケーション (または「MVP」) として造語するだけでは、あまり明確になりません。たとえば、サーバー側の MVC (ASP.NET MVC など) やクライアント側の Javascript を使用した MVC、またはその両方である可能性があります。
アーキテクチャ オプションに関するご質問に関しては、活躍の場はかなり広いです。通常、行う選択は、アプリケーション要件を収集する際に収集する必要がある多くの要因によって異なります。
多くの場合、スケーラビリティと複雑さの間でトレードオフを行う必要があります。しかし、多くの新しいテクノロジーにより、このトレードオフは無視できるものになっています。新しいプロジェクトを開始する人には、それらを真剣に検討することをお勧めします (一部については以下で説明します)。
ほとんどの場合、物理的に専用のデータ層 (SQL、Mongo、Azure、Amazon から選択してください) と専用のスケーラブルなロジック層 (最近では通常、.NET ランドで WCF サービスとして実装されています) を用意するのが最善です。
ほとんどの場合、人々は Web サイトやロジック層に参加しますが、必ずしもそうである必要はありません。Web サイト層からのみアクセスできる Web サービス専用の物理層を用意することが理にかなっている場合があります。繰り返しますが、それはすべて状況依存です。
論理レイヤーに関する限り (ロジック層内)、何らかのデータ アクセス レイヤー (DAL)、コード内モデル (手動で実装するか、LINQ-to-Entities などを介して実装するか) を使用することがほとんどの場合に最適です。専用のビジネス ロジック層。
最近では、(JQuery、Prototype、DOJO などの助けを借りて) 従来の HTML や Javascript に戻り、REST/JSON を使用して Web サービスとチャットし、クライアントでデータを取得および表示する人が増えているようです。側。このシナリオでは、クライアント側に本格的なアプリケーションを配置し、バックエンドに別の本格的なアプリケーションを配置することができます...それぞれに、上で説明した論理レイヤーの独自の実装があります。
選択肢は広く開かれています。