3

私は最近、この投稿を読み、すべてが同じ考えを示唆しているように見える一連の他の投稿につながりました: モデルはすべてを行い、ビューはモデルと直接通信できる必要があり、コントローラーは邪魔にならないようにします。ただし、示されている例はすべてかなり単純化されており、リクエスト/レスポンス サイクルの完全な処理を実装しようとした例を実際に示している例はありません。 $_GET、$_POST など) 自体は?" 「コントローラーは、必要なモデルをインスタンス化し、モデルをビューに渡すためのパススルーとしてのみ動作する必要がありますか?」。(実際、モデルに Zend_Form オブジェクトを埋め込む極端な例を 1 つ見つけました)

Fowler が MVC とコントローラーについて一般的に述べていることを読んだところ、一見したところ、コントローラー レイヤーが薄いほど優れているように思えます。しかし、私は時間をかけて MVC とフロント コントローラーの両方について彼が言っていることを調べました (両方のパターンがコントローラーを定義するため、混乱を招くだけです)。 MVC で Controller の機能を実行し、Front Controller で Command オブジェクトの機能を実行する複合オブジェクト (またはそのようなもの)。

したがって、アプリに同様のパターンを実装した他の人の一般的な意見はどうなるのだろうかと思います-コントローラーレイヤー内でリクエストを完全に処理しますか、それともモデルにリクエストを認識させ、モデル内でパラメーターを直接処理しますか?

4

2 に答える 2

4

私が最初に考えたのは、モデル内であらゆる種類のリクエストを処理しないようにすることです。それがコントローラーの仕事です。理由は次のとおりです。リクエスト (GET または POST) を処理するモデルがあるとします。その構造は、おそらく最初はうまくいくでしょう。ここで、ある種の AJAX 機能を追加したり、システムにサービス インターフェイスを設定したりしたいとします。単純な GET/POST、つまり JSON や XML 以外のものを受け入れるようになったので、モデルは各リクエスト タイプを区別し、それらを解析する方法を知る必要があります。これは、モデル コードの単純さと明快さの多くを破壊すると思います。コントローラー層は薄くあるべ​​きだという意見には同意しますが、役割と専門知識も必要です。私にとって、コントローラーの専門知識は次のとおりです。

  1. 着信要求を処理する
  2. モデルへの配信データ
  3. モデルからデータを要求/受け入れる
  4. データのモデルをビューに渡す

ビューがモデルについてどれだけ知っているべきかについて、私は動揺します。モデルをそのままビューに入れることを推奨する人もいますが、それは脆弱な結合だと思います。ビューのロジックにつながることがよくあります。また、ビューに取り組んでいるチーム メンバーが主要な開発者ほどプログラミングに精通していないプロジェクトに取り組んでいる場合、変更についていくために大きな負担がかかります。ビューに渡すデータは、完全なモデルを渡すのではなく、ニュートラルな構造でパッケージ化する傾向があります。

私の MVC の解釈は、ほとんど実用的です。モデルの仕事は、作業しているドメインをモデル化することであり、データがどこから来るかは気にするべきではありません。私はしばしば、コマンド ライン アプリケーションやデスクトップ アプリケーションなど、Web アプリケーションの外部で使用できるという前提でモデル コードを構築します。このような結合はめったに起こりませんが、各レイヤーの明確な目的につながります。コントローラーの仕事は、クライアントの要求、モデル、ビューなど、関係者間でデータを移動することです。コントローラーにはドメイン ロジックがほとんどないはずですが、コードがないわけではありません。最後に、ビューはきれいに見えるはずです。それが役立つことを願っています。

于 2009-01-12T02:42:18.230 に答える
3

ユーザーの指示/入力 (HTTP 要求など) の処理はコントローラーの仕事です。モデルはデータの作業/操作/取得用であり、ビューは結果をユーザーに表示するためのものです。これは、ほとんどの場合、ビューとモデルの間の接続がコントローラーの役割であることを意味します。

于 2009-01-11T10:30:34.573 に答える