3

私はその答えを探しましたが、誰もがそれについて異なる理解を得たように見えました:(3層/3層と比較して)

"

モデル - ビジネス ロジック

表示 - プレゼンテーション ロジック

コントローラー - モデルとビューの状態の変更 (使用入力に基づく)

"

他の人は書いた：

" ビュー = フロントエンド (プレゼンテーション ロジック)

モデル = バックエンド (データ アクセス層?)

controllers = フロントエンドとバックエンドの間の接着剤 (中間層? ビジネス ロジック) "

私が正しく理解していれば：

モデル - ビジネス ロジック層ですか?

ビュー - プレゼンテーション層\レイヤーですか?

コントローラ - ?

4

5 に答える 5

2

MVC はさまざまなコンテキストでさまざまなことを意味するため、答えは見た目ほど単純ではありません。

クラシック MVC (Smalltalk、C++、Java)

クラシック MVC

  • モデルにはデータが含まれています
  • ショーのデータを見る
  • コントローラの更新データとプロセスのユーザー操作

Web アプリケーションの MVC

Web アプリケーションの MVC

  • ビューはレンダリングされた HTML です
  • コントローラはレンダラー / リクエスト プロセッサです
  • モデルはデータを保持し、レンダラー / リクエスト プロセッサによって使用されます

ASP.Net MVC の MVC

ASP.Net MVC の MVC

  • ビューはレンダリングされた HTML です
  • ASP.Net スタックと MVC スタックが要求とレンダリングを処理します。
  • ASP.Net MVC ビューは、HTML をレンダリングするためのレンダリング命令です。
  • ASP.Net MVC コントローラーは、スタックから要求を受け取り、ASP.Net MVC ビューを使用してレンダリングされた HTML ページを生成するソフトウェア コンポーネントです。
  • モデルはデータを保持し、ASP.Net MVC コントローラー (サービスやエンティティ フレームワークなどを使用してその作成も担当) と ASP.Net MVC ビューによって使用されます。

MVC (3) パイプラインの完全なビューについては、このドキュメントを参照してください。

于 2013-01-09T12:28:24.430 に答える
2

View = 出力および出力ロジックのみ

モデル= データ関連のデータはすべてモデルから取得する必要があります

コントローラ= View と Model を接続し、アプリケーション ロジックを実行できるもの

ビジネス ロジック = 通常はクラスにパッケージ化された追加のビジネス ロジック。

ユーザーが acme.com/home をくれと言う コントローラーが言う、/home で何をするか知っているビューがアクセスできる場所 (viewbag) このビットは、applicationLogic homeController と呼ばれることもあります。それから、OK と答えます。私たちのために用意されたコントローラ

コントローラーがすべてを制御し、ビューは何も話さないことを思い出してください。これは単純な正しい図です。多くの図は異なり、解釈は自由だと言えますが、ビューがモデルに話しかける図は MVC imo ではありません。

MVCシンプルな MVC ダイアグラム

于 2013-01-09T11:06:14.600 に答える
0

それらは階層的に依存しています：

モデル-生データモデル、コントローラーのオブジェクト抽出

コントローラ-モデルからのデータがビュー用に変換される方法を制御します

ビュー-プレゼンテーション層、コントローラーからデータを抽出してきれいにします。

XMLの場合、これは次のとおりです。

XML-> XSLT-> HTML

于 2013-01-09T10:51:00.100 に答える
0

私は次のように見る傾向があります。

モデル: ブループリント、ほとんどが私のオブジェクト クラスです

表示: ユーザーにどのように表示されるか、私はどのように表示するか

コントローラー: 実行する必要がある計算、変更、...。ビューとモデルの間のステップとして機能します。データを操作します。

于 2013-01-09T10:41:58.503 に答える
0

あなたはすでに混乱しているように聞こえるので、もう 1 つの意見が役立つかどうかはわかりません。

しかし、MVC は実際にはSmalltalk の時代にさかのぼる古い概念であり、修正が必要だと思います。

より現代的なアプローチは、レイヤーの観点から考えることです。

View --> Controller --> Service --> Persistence

レイヤーは、Viewエンド ユーザーに表示される HTML またはモバイル ビュー ページです。

Controllersと密結合していViewます。を変更すると、 もView変更する必要が生じる可能性がありますController。からのリクエストをリッスンし、View入力パラメーターを検証してバインドし、それらを に渡してServicesユース ケースを満たし、適切な next を決定しView、レスポンスをエンド ユーザーにシリアル化します。

ユースケースにServiceマップし、作業単位を実行します。取引を担当しています。それは独立していViewます; 変わってもくっつきそうViewsです。これは、サービス指向アーキテクチャの基礎です。EJB、SOAPまたはREST Webサービス、XML-RPCなど、好みのテクノロジーを使用してデプロイできるインターフェースとして開始する必要があります。

Persistenceデータベースを他の人から隠します。すべての CRUD 操作を処理します。

Modelすべてのレイヤーの間に浮かんでいます。これらは、解決しようとしている問題を説明するオブジェクトです (例: バンキングの Account、Customer など)。

「図」の矢印は意味があります。この配置でオブジェクトが持つパッケージの依存関係を模倣します。 Persistenceについては知りませんService。Serviceについては知りませんController。

これらはインターフェースベースである必要があるため、クライアントに影響を与えることなく実装を変更できます。

于 2013-01-09T10:42:53.173 に答える