2

ここ数日から、C# を使用して ASP.Net で開発される新しい Web アプリケーションに最適なアーキテクチャを探していました。今までは以下の3つしか見つけて勉強していませんでした

  • 3 層アーキテクチャ (注: 層とは、論理層を意味します)
  • モデル ビュー コントローラー (MVC)
  • モデル ビュー プレゼンター (MVP)

私の質問は次のとおりです。

1) 3 層アーキテクチャと MVP を理解している限り、MVP と 3 層は同じものだと言えますか? そうでない場合、両方の違いは何ですか? (注: 私は MVC と MVP、または MVC と 3 Tier Archi の違いしか見つけていませんが、MVP と 3 Tier Archi の違いについては誰も指摘していません)

2) 上記の 3 つのアーキテクチャ オプションしか見つかりませんでした。他のオプションも利用できますか? (注: ここでは、上記 3 のように、Web アプリケーションの全体的なアーキテクチャのオプションのみが必要です)

4

3 に答える 3

7

ソフトウェア アーキテクチャの観点から。用語は何かを意味するため、用語を使用します。「3 層」などの用語を使用する場合は、その意図と理解に適した場所で使用する必要があります。あらゆる種類のものは、何らかの種類の個別のコンポーネントが 3 つあるという理由だけで、「3 層」と見なすことができます。しかし、MVP を説明するためにその用語を使用すると、相手を誤解させることになります。簡単に「MVP」と言わないのはなぜですか?

3 層とは、一般に 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 サービスとチャットし、クライアントでデータを取得および表示する人が増えているようです。側。このシナリオでは、クライアント側に本格的なアプリケーションを配置し、バックエンドに別の本格的なアプリケーションを配置することができます...それぞれに、上で説明した論理レイヤーの独自の実装があります。

選択肢は広く開かれています。

于 2011-07-06T06:25:54.567 に答える
1

私の見解:

3 層は MVP/MVC と同じではありません。

多くの人々は、「モデル」を、多くの動作 (ドメイン ロジックを含む) を含む可能性のある非常に広い概念として解釈しています。私はしません。モデルは、ビューがそれ自体をレンダリングするために必要なものです。動作する場合もありますが、ビューのレンダリングに関連する動作のみです。

MVP を使用すると、ビューとプレゼンターの間に 1 対 1 のマッピングができます。概念的にはもっと多くできるかもしれませんが、実際にはそうはならないでしょう。プレゼンターは、他のレイヤーとビューの間の仲介のみに関心があります。

MVC では、コントローラーがフローに関係しているため、コントローラーが処理するビューが 1 つ以上存在する可能性があります。

したがって、MVC/MVP は一緒に使用でき、フロントエンドに関連しており、n 層アーキテクチャの一部です。

それが理にかなっていることを願っています。

于 2011-07-06T06:55:35.773 に答える
0

このような回答で、MVP と MVC とは何ですか? その違いは何ですか? その MVC と MVP は、UI に関係するコードの構造に対処しています。次のような質問に対処します。

  • ユーザーのアクションを理解するのはどのコンポーネントですか?
  • 次に表示するビューを決定するコンポーネントはどれですか?
  • ビューとモデルの関係は何ですか?

MVC も MVP も、モデルの内部 (または下) の詳細には触れません。一部のシステムでは、モデルは比較的単純で、データベース上の薄いスキンにすぎません。他のシステムでは、SAP や CIC などのエンタープライズ システムとの統合など、非常に多くのロジックが存在します。

従来の意味では、3 層アーキテクチャ (より一般的には n 層アーキテクチャ) は、モデル内に追加の構造を配置します。

このウィキペディアの記事では、MVC v n 層アーキテクチャについて説明しています。この記事では、MVC を MVP に置き換えるのが妥当だと思います。

アプリケーションのアーキテクチャに関して: 私の認識では、最近のアプリはブラウザーに豊富な UI が表示される傾向があり、サーバー上のモデルによって提供される単純な REST サービスと、モデル内の任意の複雑なものを使用する傾向があります。これは n 層アーキテクチャと見なすことができると思います。興味深いことに、ブラウザーで Javascript (JQuery、Dojo など) を構造化すると、デザイン パターンが表示され、MVC パターンは実際には純粋にプレゼンテーション層に表示されます。

于 2011-07-06T06:28:14.990 に答える