10

コントローラーは軽く、モデルは重くする必要があると聞きました。

コントローラに何を保持する必要があるのか​​、モデルに何を保持する必要があるのか​​についてのベストプラクティスについては少し混乱しています。

私たちの組織では、Entity Frameworkを使用して、そこにテーブルを配置しています。

コントローラの場合、LINQを使用してから、情報をビューに送信します。

コントローラとモデルにどのコードを含めるべきかについて、ちょっと混乱しています。

4

6 に答える 6

11

免責事項
全体のトピックは巨大な混乱です。特にWebMVCに関しては。ビューはモデルを観察する必要があるため、すべての実用的な目的で、Webに従来のMVCパターンを使用することは不可能です。理論的には、WebSocketを使用してそのようなものを実装できますが、ユーザーごとに永続的なモデルを維持することは現実的な解決策ではありません。

MVCについて知っておくべきことは次のとおりです

古典的なMVCとMVCに触発されたパターンの両方で最も重要なアイデア関心の分離。アプリケーションを2つの主要なレイヤーに分割します。

  • プレゼンテーション層

    ユーザーインターフェイスを管理します。インターフェイスの作成と、ユーザーによるこのインターフェイスの操作の両方を処理します。このインターフェースは、デスクトップアプリケーションまたはHTML WebページのGUIである可能性がありますが、RESTAPIまたは火星探査車のレシーバーレスポンダーである可能性もあります。これが、Webアプリケーションがフロントエンドとバックエンドの両方でMVCパターンを実装できる理由です。

    必須の部分はビューとコントローラーですが、Webのコンテキストでは、完全に実現されたビューは通常、複数のテンプレートを使用してインターフェイスを作成します。

  • モデルレイヤー

    これは、すべてのビジネスルールとロジックが存在する場所です。MVCのMは単一のエンティティではありません。代わりに、さまざまな構造を含むレイヤーです。これらの構造の一部は、ストレージとの相互作用にも関与しています。

コントローラーの責任は何ですか？

コントローラは、ユーザー入力を処理するプレゼンテーション層の一部です。Webベースの実装のコンテキストでは、通常、ビューとコントローラーの間に1：1の関係があり、コントローラーはブラウザーから要求を受け取り、その要求の内容に基づいて、モデルレイヤーとビューの状態を変更します。

従来のMVCまたはModel2MVCを使用している場合、それがコントローラーの責任の範囲です。

パッシブビューがあるMVPおよびMVVMパターンでは、コントローラーのような構造がモデルレイヤーから情報を取得し、それを現在のビューインスタンスに渡す役割を果たします。この投稿では、MVCに触発されたパターンに関する追加の詳細が提供される場合があります。

ただし、コントローラは、いかなる形式のビジネスロジックにも一切責任を負いません。もしそうなら、それはあなたが漏れている抽象化を持っていることを意味します、なぜならプレゼンテーション層の構造が仕事をしているからです、それはモデル層にあるべきです。

通常、コントローラーはアプリケーションで最も単純な構造になります。

モデルはどうですか？

前述のように、モデルは、ドメインのビジネスロジックと関連機能のすべてを含むレイヤーです。この層は、プレゼンテーション層と同様に、複数の構造グループで構成されています。

  • ドメインオブジェクト[1]

    これらの構造は通常、「モデル」について話すときに人々が意味するものです。これらは、モデルオブジェクトまたはビジネスオブジェクトとも呼ばれます。これは、ドメインビジネスロジックのほとんどが終わるところです。

  • データストレージ構造

    このグループには、ストレージとの相互作用を抽象化するすべてのクラス（SQLデータベース、キャッシングシステム、noSQL、リモートSOAP、またはREST API）が含まれます。通常、データマッパーまたはリポジトリパターンのバリエーションを実装しますが、作業単位など、他のソリューションを使用することもできます。実装の詳細はそれほど重要ではありません。重要なのは、ドメインオブジェクトからデータを保存したり、ドメインオブジェクトに情報を取得したりできることです。

  • サービス

    または、「コンポーネント」と呼ぶこともできます。モデルレイヤーには高レベルの抽象化があり、ドメインオブジェクトとストレージ構造の間の相互作用を容易にします。通常、「認識サービス」、「メーラー」、「記事管理」などのモデルレイヤーの大きなチャンクを表し、プレゼンテーションレイヤーが対話するためのインターフェイスを提供します。

于 2012-08-19T15:21:24.843 に答える
1

それは宗教的な議論のようなものです。コントローラーのコードをできるだけ少なくしたり、モデルのコードをできるだけ少なくしたりする人もいます。プロジェクトで自然に感じることを実行しますが、プロジェクト内で一貫性を保ちます。

他のすべては教義であり、どちらの方法でも例を選んで主張することができます。

于 2012-08-17T21:11:43.457 に答える
0

Model is the core of your application. It is best to think of models as of your business entities. Do you want to create a view of an invoice? Then Invoice be your model, it represents the underlying object.

Controller is just a way to handle requests from a client, retrieving the data from database (or updating them) and flushing out the responses.

Your thoughts about the application design should be model-centric, that's the important part.

于 2012-08-17T20:43:11.083 に答える
0

簡単に言うと、モデルは、アプリケーションが使用する基礎となるデータを表します。さまざまなアプリケーションで使用できるように設計する必要があります。たとえば、ニュースデータを表すモデルは、コンソールコマンド、Webサービスなどで使用できます。これは、ビューに関係なく、ビジネスロジックを定義するモデルです。

コントローラは、モデルとビューを結合する接着剤と考えることができます。クライアントのリクエストを直接処理し、それに応じてビューやモデルとやり取りします。

適切に設計されたアプリケーションでは、データ構造とビジネスロジックがモデルで設計され、「重い」ものになります。Controllerはモデルとビューをクライアントのリクエストと相互リンクするだけですが、「軽量」になります。

于 2012-08-17T20:55:02.790 に答える
-1

私はMVCの専門家ではありませんが、コントローラーがユーザーからの入力を使用してユーザーを正しいビューに誘導する必要があるという事実に集中してみてください。

NerdDinnerが理想的な例であるかどうかはわかりませんが、Scott Hanselman et alが彼のEFコンテキストから少しデータアクセスを行っているが、他のほとんどのロジックをモデルのサービスクラスまたはヘルパーにプッシュしていることがわかります。

モデルを「ビジネスオブジェクト」として使用していないため、「モデルが重い」部分に同意するかどうかはわかりません。本当に多くの「ビジネス」ロジックが必要な場合は、通常、それを別の「ドメイン」レイヤーに作成し、その上に別のデータアクセスレイヤーを配置することもできます。しかし、多くの単純な（非企業を参照）プロジェクトの場合、これは私の経験ではやり過ぎです。

于 2012-08-17T20:40:26.733 に答える
-1

従来のModel-View-ControllerMVCパターンでは、モデルは本質的に「ヘッドレス」アプリケーションであり、UIはなく、完全にUIに依存しません。これは、アプリケーションの機能コアであるAPIを提供します。

ビューはユーザーインターフェイスですが、定義することを選択します（Webページ？エレベータコントロールパネル？他の何か？）。特定のアプリケーションには1つのビューがある場合と、多数のビューがある場合があります。

コントローラー（またはビューのように、特定のアプリケーションに対して1つから複数のコントローラーがある場合もあります）は、イベント、通知、およびデータをビューとモデルの間で中継および変換して、モデルがビュー固有の情報を知る必要がないようにします。

アイデアは、コアアプリケーション（モデル）をユーザーインターフェイス（ビュー）から分離することです。それからいくつかのことが続きます：

  • ビューはコントローラーとモデルの両方を認識して通信し（ビューを別のモデルに接続しようとする可能性は低いです）、コントローラーがビューとモデルの両方を認識していることを期待します。

  • コントローラは、ビューとモデルの両方を認識し、通信します。

  • モデルはコントローラーやビューについて何も知りません。

ビジネスロジックを実行するコードは、コントローラーではなくモデルに含める必要があります。

于 2012-08-17T21:09:21.553 に答える