8

Model-View-Controller デザイン パターンについて質問があります。モデルがデータを保持していることを理解しています。また、コントローラー (ビュー コントローラー) がアプリのロジックを実装することも理解しています。たとえば、UIPicker ホイールが行 4 を選択した場合、View Controller はモデルの配列に格納されている 4 番目のオブジェクトをモデルに要求できます。「ビュー」が収まるかどうかを理解するのに苦労しています。そのペン先/ストーリーボードファイルは「ビュー」として分類されると思います。ただし、すべてのビューでは、すべてのアウトレットをビューに接続するためにビュー コントローラーを接続する必要があります。View と View Controller を分離しておくにはどうすればよいですか? すべてのアウトレットを「ビュークラス」に配線してから、ビューコントローラーで「ビュー」を参照する必要があります それらのアウトレットのロジックを実装するときのクラス?View と View Controller が異なるタスクを処理する例が必要なだけかもしれません。そうしないと、追加の「ビュー」クラスが意味をなさないように見えるからです。MVC のビューはビュー クラスを参照していますか? このビュー クラスをビュー コントローラー クラスから分離する方法または理由を教えてください。

4

4 に答える 4

14

ビューの仕事は、データを表示し、イベントを報告することです。

コントローラーの仕事は、ビューとモデル間の通信を調整することです。

データの役割は、データを保存することと、そのデータに関するビジネス ロジックを提供することです。

あなたは尋ねました:

「ビュー」が収まるかどうかを理解するのに苦労しています。

あなたの例でUIPickerViewは、ビューです。

iOS/OSX では、View Controller は単なる MVC のコントローラーです。ビュー コントローラーには、他のすべてのビューを追加できる空のビュー コンテナーも含まれていることがあります。しかし、iOS/OSX では MVC が明確に分離されています。

UIButtonUIPickerView、などのクラスはすべてUITableViewビューを表します。ビュー コントローラーの仕事は、これらのビューにデータ モデルからのデータを提供することと、それらのビューからのイベントに応答して、他のビューやデータ モデルを更新する機会を与えることです。

また、次のようにも述べています。

ただし、すべてのビューでは、すべてのアウトレットをビューに接続するためにビュー コントローラーを接続する必要があります。View と View Controller を分離しておくにはどうすればよいですか?

それらは別々です。を追加するUITableViewと、それは別のビューになります。これをクラスに接続して、クラスがデータ ソースとデリゲート メソッドを実装できるようにします。そのクラスはコントローラ クラスです。このコントローラー クラスがビュー コントローラーであることは一般的ですが、そうである必要はありません。特定のビュー コントローラー (またはジェネリック コントローラー) から独立した、あらゆる種類のカスタム ビュー クラスを作成できます。しかし、最終的には、データとイベントを適切に処理できるように、そのビュー クラスを [ビュー] コントローラー クラスに接続する必要があります。

あなたは尋ねました:

このビュー クラスをビュー コントローラー クラスから分離する方法または理由を教えてください。

を見てくださいUITableViewController。これは分離の明確な例ですが、かなりきちんとしたパッケージで提供されます。実際にUITableViewは、ビューである別のクラスがあります。このビューは、ビューのレンダリングとユーザー インタラクションの収集を担当します。ビューにデータを提供し、ビューからのユーザー イベントを処理するのは、実際のテーブル ビュー コントローラーです。

UITableViewビューを任意のビューに追加できます。これは完全に再利用可能なビュー コンポーネントです。テーブル ビューに接続する各コントローラーは、適切なデータを提供し、ユーザー インタラクションを適切に処理できます。

于 2013-02-05T23:27:14.393 に答える
1

わかりました、私は物事を少し整理しようとします。

このパターンは Model-View-Controller と呼ばれ、Model、View、Controller が明確に分離されています。あなたが正しく指摘したように、ViewController は (View と Controller から:) 物事をまとめ、実際には ViewController は強力な MVC パターンを壊します。幸いなことに、ViewController を使用している場合は、ビューとコントローラーを分離する必要はありません (なぜそのような名前が付けられているのでしょうか?)。

なぜデザインがそれであるかについての私の説明:

ビューとコントローラーを強く分離すると、基本的に優れた設計のクレジット ポイントを獲得できます。しかし、結局のところ、それらの 2 つは、私たちが望んでいるほど分離されていません。通常、異なる GUI 表現には、異なるビューの実装と、モデルの GUI への転送を制御するコントローラーの適応が必要です。たとえば、コンソールでのプレーン テキスト表示とビットマップでの描画などです。最初のケースでは、Controller はレンダリングされるビューに文字列を渡します。2 番目のケースでは、適切な場所にレンダリングされるテキストを取得するために、いくつかの座標も設定する必要があります。したがって、コントローラーは頻繁に変更されます。

理想的なケースは、モデルとコントローラーを実装し、誰もが実際にライブで見ることになるものすべてのビューを提供することです。ただし、実際の状況では、コントローラーはモデルをそのままにしてビューに適応する可能性が最も高くなります。したがって、ビューとコントローラーを特定のビューを含み、その使用方法を知っている ViewController に結合するという設計上の決定は、合理的な方法です。

于 2013-02-05T21:58:35.870 に答える
1

実際、あなたが理解していることは完全に間違っています。

MVC デザイン パターンの背後にあるコア原則は、関心の分離です。モデル レイヤーをプレゼンテーション レイヤーから分離し、(プレゼンテーション レイヤーで) ビューをコントローラーから分離します。

各パーには異なる責任があります。

  • モデル層にはすべてのビジネス ロジックが含まれます。これには、ストレージ、ドメイン ロジック、およびアプリケーション ロジックとのやり取りが含まれます。
  • view は UI ロジックを担当します。これは、Web のコンテキストでは、そのビューがユーザーへの応答の作成を処理することを意味します。
  • コントローラーはユーザー入力を受け取り、それに基づいてモデルレイヤーと現在のビューの状態を変更する部分です。

MVC については、人々が永続させる傾向があるという誤解がたくさんあります。例えば:

  1. ビューは馬鹿げたテンプレートだと主張する人もいます。ではない。

    MVC デザイン パターンのビューは完全に機能するインスタンスであり、複数のテンプレートを使用して応答を生成する場合と使用しない場合があります。

  2. 「モデル」はありません。モデルは、それぞれが特定のタスクを持つ複数の異なるクラスのグループで構成されるレイヤーです。プレゼンテーション層に「プレゼンテーション」オブジェクトがないのと同じ方法

  3. コントローラーは、モデル レイヤーからビューにデータを送信しません。コントローラーは、トライアドの他の部分の状態のみを変更します。ビュー インスタンス自体は、モデル レイヤーから必要なものを要求します。

于 2013-02-05T22:18:28.820 に答える
0

あなたの質問に答えるために、MVC - モデル、ビュー、コントローラーを分解しましょう。何がどこに行くの?

モデルは通常、「何かをする」レイヤーと見なされます。これは、ビジネス ロジックとデータ ロジックを保持します。モデルは SKINNY ではなく FAT である必要があります。つまり、モデルに多くのコードを含める必要があります。

Controller 、私は「応答」層を考えます。ここで、ユーザーに何を返すかを決定します。それがビューであるか、JSON などの他のタイプの応答であるかに関係なく (特に RESTful 応答で役立ちます)。モデルも使用できますが、コントローラー自体に多くのロジックを組み込むべきではありません。SKINNY コントローラーが必要です。

Viewは主にページのマークアップ(モデルにアクセスするための HTML とその他のマークアップ) です。これは、使用しているフレームワークによって異なります。私の経験は MVC .NET に関するものなので、それを使用します。HTML と組み合わせて、Model 要素にアクセスします。ビューには実際のロジックはありませんが、次のようなことができます (Razor 構文を使用)

<div>@foreach person in Model.Users{
    <p>@person.FullName</p>
}
</div>

したがって、ビューにはいくつかの「表示ロジック」(人をループして FullName を取得するなど) を含めることができますが、実際に必要なのはそれだけです。

「モデルはデータを保持し、コントローラーはロジックを保持する」という最初の説明が実際には正しくない理由など、MVC について詳しく説明する簡単なスライドショーを次に示します。 -models-proper-code-structure-for-mvc

MVC デザイン パターンには、「ViewController」と呼ばれるものは含まれていません。これは別の場所から来ています。

于 2013-02-05T22:09:47.557 に答える