20

以前は、多くの開発者は、ほとんどのフレームワークが行うように、ビューはモデルと直接通信するべきではないという意見を持っていました。

そして、この意見は間違っているようです。いくつかの記事を見つけました。これらの記事では、ビューはモデルと直接通信できると書かれています。

http://r.je/views-are-not-templates.html
http://www.tonymarston.net/php-mysql/model-view-controller.html
モデル、ビュー、コントローラーの混乱
と
モデルのあり方MVCで構造化？

これらの記事のほとんどは、ウィキペディアのModel–view–controllerからのブロックを引用しています。引用は次のとおりです。

ビューは、適切なユーザー インターフェイスを生成するためにモデルにクエリを実行します (たとえば、ビューはショッピング カートの内容を一覧表示します)。ビューはモデルから独自のデータを取得します。一部の実装では、コントローラーはビューに一般的な命令を発行して、それ自体をレンダリングする場合があります。また、画面の更新が必要な状態の変化 (オブザーバー) のモデルによって、ビューが自動的に通知される場合もあります。

ああ、それはウィキペディアからのもので、そのような権威のあるサイトです。それは正しいに違いありません!

しかし今、MVC http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controllerの wiki リンクを開くと、ページは今年の 9 月 14 日に編集されています ( 2013)、上記の文はなくなりました。

ビューの新しい定義は次のとおりです。

ビューは、コントローラーを介してモデルから、ユーザーへの出力表現を生成するために必要な情報を要求します。

今、私は再び混乱しています。新しい定義では、ビューはコントローラーを介してモデルからデータを要求する必要があります...

ビューは地球上でモデルに直接アクセスする必要がありますか?

4

4 に答える 4

16

「モデル」はコア アプリケーションです。アプリケーションでできることはすべてモデルにあります。
「ビュー」は、何が起こっているかを視覚化し、ユーザー インターフェイスを提供するためにあります。
「コントローラー」は、イベントに反応し、モデルに指示を出し、何をすべきかを表示するために必要な接着剤です。

では、モデルとビューの間の通信にはどのようなオプションがありますか?

  1. プッシュ: ビューが必要とするすべてのデータは、通常はコントローラーによってプッシュされます。
  2. プル: ビューは、必要な場所から必要なすべてのデータを取得します。

2 つ目は明らかに自己完結型です。ビューにデータをプッシュする必要がある場合、それは、ビューの外にいる誰かがビューが何を望んでいるかを知る必要があることを意味します。特にビューは非常に動的で、頻繁に変更される可能性があります。誰かが右上隅にもう 1 つのウィジェットを表示することを決定し、突然ビューに追加のデータが必要になりました。つまり、より多くのデータをビューにプッシュするには、他の部分を再コーディングする必要があります。したがって、ビューが変更されたという理由だけで、少なくとも 2 つの独立した部分を変更する必要があります。

より良いオプションは、モデルと対話し、必要なすべてのデータを取得できるようにするハンドルをビューに与えることです。コントローラーはビューに「フォーム XYZ が必要です。ここにモデルと対話するためのハンドルがあります」と伝えるだけです。ビューはその仕事をすることができます。

于 2013-09-18T13:10:17.697 に答える
1

人々は概念、用語、慣習をめちゃくちゃにしているので、コミュニケーションさえ難しいと思います。

MVC はプレゼンテーション レイヤー アーキテクチャの形式であることはわかっています。そのため、何らかの理由で UI に特定のビジネス ルールを複製したい場合を除き、そのコンポーネントにビジネス ロジックを含めるべきではありません。ASP MVC のようなフレームワークのビューモデル クラス内に (ほとんどの) ビジネス ロジックのようなものを詰め込むと、問題が発生すると思います (彼らは、MVC はこれを禁止していないと主張していますが、正しいレイヤリングが禁止されていることを無視していると確信しています)。 ...)。

次に、ビジネスレイヤーがビューモデルとマージされ、プレゼンテーションレイヤーとマージされます...

プロジェクトに何らかのレイヤーを入れたい場合、これは絶対に避けるべきだと思います。

少なくとも、これに対する私の見解は...

于 2014-11-10T16:28:13.800 に答える
0

MVCに関するほとんどの引用は一般的には問題ないと思いますが、あなたが話しているのは...具体的に言って、実際にそれを呼んでみましょう... Microsoft View Controller. 彼らは常に独自の要素を少し追加する傾向があるため (多くの人は同意しませんが、私の意見では、ほとんどの場合、彼らの意図は適切に形成されていると思いますが、これは別のトピックの議論になります)。

Microsoft-View-Controller は実際には Model-View-Controller テーマの別のバリアントであることを強調したかっただけです。

私がそれを使用する方法は次のとおりです。

私は一般的に、さまざまなパターンを使用して懸念事項を分けています。率直に言うと、どのシステムでも最も遅い部分の 1 つはデータ アクセスであり、それに続いて帯域幅が続きます。したがって、多くの人が提案するようにモデルにビジネス ロジックを組み込むことは、次の 2 つの理由から間違っていると強く感じています。

  1. MVC (バリアントに関係なく) は、拡張可能で保守可能になるように設計された開発の方法論です。
  2. Microsoft-VC では、ビューを複数のモデルに接続する方法はありません (ViewModel を使用しない限り)。このプラクティスは奨励されており、バックエンド モデルとの直接接続に関連するセキュリティ上の懸念が数多くあります。必要であろうとなかろうと、ビューをモデルに直接接続することは一般的に悪い習慣と考えられており、代わりにそれらを ViewModel に接続する必要があります。

MVC は階層化されたアーキテクチャです。だから重ねる。つまり、テーブルをクラスにマッピングするジョブを EF に任せて、そのままにしておくということです。Microsoft-VC は、「部分」クラスを使用してコードを自動生成することにより、デザイン パターン (オープン/クローズの原則) をモデルに適用することをユーザーに強制します。したがって、独自の空の部分クラスを作成し、これにメタデータを追加します。モデルと密結合になるため、ここにコードを追加することはお勧めできません。その代わり...

リポジトリ パターンを使用してリポジトリ レイヤーを追加します。これは、すべてのモデル クラスを使用して、基本的な (非常に基本的な) CRUD を実行します。それで...

ドメイン (ビジネス) レイヤーを追加し、レポ レイヤーを呼び出して、ビジネス ルールを実行するために必要なデータを取得します...その後...

コントローラーをビジネス レイヤーのみに接続し、automapper などのツールを使用して、ドメイン レイヤーから返されたデータをビューのビュー モデルにマップします。

この経験を積むにつれて、後で必要に応じてレイヤー間にインターフェイスを追加でき、よく知られている IOC パターンを何らかの形式の DI で簡単に適用できます。

これがお役に立てば幸いです...しかし、一般的に、MVC が階層化されたアーキテクチャであるという事実は、レイヤーを追加することが設計されていることを意味するため、1 つの方法だけで作業することに制限しないでください。また、N 層の多層アーキテクチャは大規模システム用であると人々が言っ​​ているのを聞いたとしても、これはナンセンスです...すべてのシステムは大規模システムです。小さなシステムを開発するために少なくとも数十万ドルを投資する可能性がある企業はありません（私は、そのようなシステムを開発するために多額のお金を受け取っていることを知っています. 2 人以上の開発者を雇用している企業は、いわゆる「小規模」システムの開発にかかる年間 10 万ドルをすでにはるかに超えていると自信を持って言えます)。

于 2014-10-10T09:29:18.240 に答える