68

MVC と 3 層アーキテクチャの基本的な違いは何ですか?

4

13 に答える 13

34

3 層はアーキテクチャ スタイルであり、MVCはデザイン パターンです。

その点で違います。

しかし、3 層アーキテクチャ スタイルで mvc パターンを使用できます。

それで：

プレゼンテーション層: MVC パターンの「コントローラーとビュー」。

ビジネス層 : MVC パターンの「モデル (データ)」。

データ アクセス層: 元のデータ アクセス層。

于 2012-12-17T08:16:32.043 に答える
33

大規模なアプリケーションでは、MVC は N 層アーキテクチャのプレゼンテーション層のみです。モデルのビューとコントローラーはプレゼンテーションのみに関係し、中間層を利用してデータ層からのデータをモデルに取り込みます。

MVC は、ビューがプレゼンテーション、コントローラーがビジネス ロジック、モデルがデータ層 (通常は Entity Framework などの DAL によって生成される) である 3 層アーキテクチャ全体として使用することもできます。

理想的には、コントローラーを薄くて馬鹿にして、ロジックを「ビジネスコンポーネント」に渡します。これは本質的に中間層になります。

于 2011-01-02T08:08:02.713 に答える
18

3 層アーキテクチャでは、層間の通信は双方向です。MVC では、通信は単方向です。各「レイヤー」は左側のレイヤーによって更新され、次に右側のレイヤーによって更新されると言えます。ここで、「左」と「右」は単なる例です。

3 層アーキテクチャは通常、3 つの個別のネットワーク ノードに 3 つの個別のプロセスとしてデプロイされます。ただし、MVC は、単一のネットワーク ノードに単一のプロセスとして展開するように設計されています。(デスクトップ アプリケーションのようなもの)

通常、3 層のビジネス層には、ビジネス デリゲート、ビジネス ファサード、ビジネス オブジェクト、サービス ロケーター、データ転送オブジェクトなどの有名なパターンを実装するさまざまなレイヤーが含まれます。しかし、MVC はプレゼンテーション層で使用されるデザイン パターンそのものです。

3 層の目標は、ビジネス ロジックをクライアントとデータベースから分離することです。そのため、複数のクライアント プロトコル、高いスケーラビリティ、異種データ アクセスなどを提供します。しかし、MVC の主な目標は、一部の実装の変更が別の部分の変更を必要としないことです。 .

于 2013-01-07T07:50:11.380 に答える
12

私は、マイケルが彼の返答で言ったこととは異なるアプローチを取ります。

コントローラーは、ビジネス ロジックになることを意図したものではありません。私にとって、ビジネス ロジックはモデル レイヤーに属します。ビュー (およびある程度のコントローラー) とプレゼンテーション層の一部ですが、モデルは MVC アプリケーションの一部ではありません。モデルは MVC アプリケーションの心臓部であり、MVC アプリケーションに簡単に実装できるドメイン駆動設計です。

同じプロジェクト内にモデルを含める必要はないことに注意してください (ASP.NET MVC について言えば)。まったく別のプロジェクトに存在する可能性があり、アプリケーションのモデルとして機能することもできます

プレゼンテーション レイヤーとしてのみ機能する MVC アプリケーションは、多くの層を持つ巨大なプロジェクトで機能しますが、質問者が尋ねた 3 層アーキテクチャでプレゼンテーションのみのレイヤーとして機能することは決してありません。

したがって、MVC は、3 層アーキテクチャの 3 つの層から 2 つ (3 番目は、MVC アーキテクチャ自体の実際の部分ではないデータ層である可能性があります) を作成すると言えます。

ありがとう。

于 2011-01-02T20:54:53.017 に答える
7

IMO では、3 層アーキテクチャと MVC を直接比較することはできません。どちらも結合して使用されるため、同じレンズを通してそれらを見る傾向があります。概念的には、これらを一緒に使用する必要はありません。MVC が提供するものを使用しない3 層アーキテクチャを使用できます。

私は定義の部分を詳しく説明していませんが、一言で言えば：

3 層はソフトウェア アーキテクチャ アプローチであり、ユーザー インターフェイス、ビジネス プロセスはロジックであり、データ層は独立して開発され、ほとんどの場合、別のプラットフォーム上にあります。

MVCは、一定期間にわたってソフトウェア パターンからアーキテクチャ パターンへと進化し、今日ではすべての主要なフレームワークで見られます。

于 2012-01-09T06:22:45.360 に答える
6

すべてのアプリケーションには、次のレイヤーが 1 つ以上あります。1) プレゼンテーション レイヤーまたは UI レイヤー 2) ビジネス レイヤーまたはビジネス ロジック レイヤー 3) データ アクセス レイヤーまたはデータ レイヤー

通常、 3 層アーキテクチャでは、各層がネットワークで分離されています。つまり、プレゼンテーション層はいくつかのWebサーバー上にあり、ビジネスロジックのためにネットワークを介してバックエンドアプリサーバーと通信し、次にネットワークを介してデータベースサーバーと通信し、おそらくアプリサーバーもいくつかのリモートを呼び出しますサービス（支払い処理用のAuthorize.netなど）。

上記のタイプのより多くのレイヤーとより多くのマシンが必要になる場合があり、それは N 層と呼ばれます

MVCは、コードのさまざまな部分がアプリケーションのモデル、ビュー、およびコントローラーを表すプログラミング設計パターンです。たとえば、モデル層には、データの保存と取得のためにデータベースを呼び出す内部実装がある可能性があるため、これら 2 つのことは関連しています。コントローラーは Web サーバー上に常駐し、アプリケーション サーバーをリモートで呼び出してデータを取得することができます。MVC は、アプリのアーキテクチャの実装方法の詳細を抽象化します。 構築したいモデルのモデル ViewはApplication の UI を意味します。 Contolは Application を制御するロジックを意味します。

3 層は、実装の物理構造を指すだけです。MVC 設計は 3 層アーキテクチャを使用して実装されることが多いため、これら 2 つは混同されることがあります。

于 2013-09-12T12:57:18.280 に答える
6

3 層アーキテクチャは線形であり、クライアント層は実際にはデータ層と通信しません。すべての通信は中間層を通過します。一方、MVC は、ビューがコントローラーに更新を送信し、モデルから更新を受け取り、コントローラーがモデルを更新する、より三角形です。

( http://en.wikipedia.org/wiki/3-tier_architectureの「MVC アーキテクチャとの比較」を参照)

于 2011-01-02T08:01:22.063 に答える
4

MVC では: MVC アーキテクチャは三角形です: ビューはコントローラーに更新を送信し、コントローラーはモデルを更新し、ビューはモデルから直接更新されます。

3 層 : 3 層アーキテクチャはクライアント層であり、データ層と直接通信することはありません。3 層モデルでは、すべての通信が中間層を通過する必要があります。

Vikas Joshi ソフトウェア エンジニア

于 2013-07-31T13:41:38.867 に答える
3

私の経験では、MVC は不適切に記述された 3 層を表すもう 1 つの「流行」用語であり、通信の一部がビジネス レイヤーを飛び越え、そのためクライアントやデータ レイヤーにもビジネス ルールが混在しています。

私はそのように書かれたコードが嫌いです - MVC という用語は、HR 採用担当者を混乱させて、年配のプログラマー (「3 層」として知られている) はその仕事に適していないと考えるように設計されたに違いありません。

于 2013-01-09T18:20:36.773 に答える
2
  • 3 層は線形アーキテクチャです。(プレゼンテーション層 -> ロジック層 -> データ層、データ層 -> ロジック層 -> プレゼンテーション層) しかし、MVC は三角アーキテクチャです。(更新ビューとモデルを制御します。モデル更新ビュー。)
  • MVC は、3 層アーキテクチャのプレゼンテーション層 (モバイル アプリケーション、Angular のような js フレームワークなど) とロジック層 (J2EE、Laravel など) に含めることができます。
  • 3 層のレイヤーは、異なるネットワーク ノードに実装できます。ただし、通常、MVC の要素は同じネットワーク ノードに実装されます。
于 2016-07-28T01:41:53.820 に答える
-8

MVC が何かを変更したり、より優れたシステムや堅牢なシステムを構築するのに役立つとは思いません。3 層アーキテクチャは成功し、十分なシステムです。私/あなたは、非常に包括的で堅牢なシステムを構築できます。複雑なウェブサイトや実際のウェブサイトでは、すべてのレイヤー間で多くの相互作用が必要であることは誰もが知っています。私は個人的に、その理由でphpが.netよりも有利であると信じています。オタクで傲慢なプログラマーに .net で簡単なフォーラム システムを構築するように依頼すると、彼はそれをレンダリングするためにどのコントロールを使用するかについて頭を悩ませるでしょう。その後、彼はデータ グリッドとリピーターを組み合わせます... しかし、後で単にコメント セクションや画像を追加するように頼んだ場合、彼は私が一体どのようにそれを行うかのようになります? 一方、phpでは... Uはhtmlとサーバーコードを混在させて、任意のプレゼンテーションレイヤーを簡単に実現できます...したがって、アーキテクチャについて自慢しないでください。メリットとデメリットは同じです。

于 2014-06-28T09:59:46.677 に答える