1

公式のModel-Glueドキュメントが提供するクイックスタートガイドに従う場合は、次の場所にあります。

http://docs.model-glue.com/wiki/QuickStart/2%3AModellingourApplication#Quickstart2:ModelingourApplication

「モデル」は、アプリケーション操作を実行するクラスのように見えます。この例ではTranslator、フレーズをピッグラテン語に翻訳するクラスを作成しました。ここから、プログラムロジックもデータベース操作クラスやHTMLヘルパーなどの「モデル」である必要があることを簡単に推測できます。

しかし、最近、MVCについてここで尋ねた質問に対する回答を受け取りました。

MVCを使用して、コントローラーによって設定されている変数の知識を必要としないようにビューを設計するにはどうすればよいですか？

回答の1つで、MVCの「モデル」は、コントローラーがデータを入力し、それがビューに渡されるオブジェクトである必要があり、ビューはそれを厳密に型指定されたオブジェクトとして使用してデータをレンダリングする必要があると述べられました。 。つまり、上記のModel-Glueの例では、トランスレータコントローラ、トランスレータビュー、PigLatinTranslatorクラス、およびTranslation次のようなモデルが必要でした。

component Translation
{
    var TranslatedPhrase = "";
}

このコントローラーは次のように使用します。

component TranslatorController
{
    public function Translate(string phrase)
    {
        var translator = new PigLatinTranslator();
        var translation = new Translation();
        translation.TranslatedPhrase = translator.Translate(phrase);

        event.setValue("translation", translation);
    }
}

そして、ビューは次のようにレンダリングします。

<p>Your translated phrase was: #event.getValue("translation").TranslatedPhrase#</p>

この場合、PigLatinTranslatorは単にどこかに存在するクラスであり、モデル、コントローラー、またはビューと見なすことはできません。

私の質問は、ColdFusion Model-GlueのモデルはMVCモデルとは異なりますか？それとも、彼らがMVCの悪い例を提供したクイックスタートガイドであり、私が上にリストしたコードはそれを行う正しい方法ですか？それとも、私はこれらすべてについて完全にコースから外れていますか？

4

2 に答える 2

5

おそらく、実装の詳細に行き詰まっていると思います。

（一般的な）MVCに関する私の理解は次のとおりです。

  • いくつかの作業を行う必要があります
  • コントローラーは、その作業がどのように行われ、どのように提示されるかを定義します
  • 最終的にモデル処理を実行するコントローラー[何かをする]
  • モデル プロセスは、[どこか] からのデータの取得、ビジネス ロジックの適用、[どこか] への結果の配置など、すべてのデータ処理を処理します。
  • 次にコントローラーは、最終的にビュー処理を呼び出して実行する[何かを行い]、モデルからのデータのビュー処理システムを利用します
  • ビュー プロセスは、期待しているデータを取得し、そのデータを何らかの方法で提示します。

それはわざと非常に抽象的です。

例はかなり不自然ですが、MGドキュメントの例はこれを適切に実装していると思います。コントローラーは、データを処理する (入力が出力に変換される) モデルを呼び出し、結果を設定します。コントローラーは、データを取得して表示するビューを呼び出します。

この質問の前提に同意しません。「MVC を使用して、コントローラーによって設定されている変数の知識を必要としないようにビューを設計するにはどうすればよいですか?」ビューは、データがどこから来るかを気にする必要はありません。必要なデータを認識し、[どこか] から取得する必要があります。モデルがどこかで使用するデータを配置し、ビューが必要なデータをどこかから取得するという、システムのどこかに規則が必要です (そうでなければ、どのように機能するのでしょうか?)。分離とは、モデルがデータを指示された場所に置くだけで、ビューはデータが指示された場所からデータを取得することです。コントローラー (または使用中の MVC システムの規則) によって、その実装方法が決まります。MGがこれを処理する方法でMVCの原則を破っているとは思いません。

このステートメントに関する限り、「この場合、PigLatinTranslator は単にどこかに常駐するクラスであり、モデル、コントローラー、またはビューと見なすことはできません。」ええと...ええ...すべてのモデルISは何らかのコードです。したがって、PigLatinTranslator.cfc は、ここでビジネス ロジックをモデル化します。

そしてこれ：「答えの1つでは、MVCの「モデル」は、コントローラーがデータを入力し、それがビューに渡されるオブジェクトである必要があると述べられていました」...それはそうではないと思います正しい。コントローラーは、要件を満たすためにどのモデルとどのビューを呼び出す必要があるかを検討し、それらの間でデータを交換する可能性があります (ただし、これは慣例によっても可能です)。コントローラーはデータ処理を行いません。どのデータ処理を行う必要があるかを決定します。

最後に、CF は強く型付けされていないため、「強く型付けされた」コメントは関連性がなく、CF 環境では適切な考慮事項ではないと思います。これはプラットフォーム固有の考慮事項であり、MVC の原則とは関係ありません。

于 2011-09-02T12:10:03.117 に答える
1

MVC に関する一般的な混乱の 1 つは、複数のビュー、複数のコントローラーがあり、モデルが 1 つしかないことだと思います。cfWheels には、永続ドメイン オブジェクトごとに「モデル」オブジェクトがあり、これは非常に紛らわしいと思いますが、もちろん cfWheels は、そのコンテキストでも「モデル」を使用する Ruby on Rails から派生しています。

一般に、MVC では、「モデル」はビジネス データとロジック全体を表します。モデルは、多数のドメイン オブジェクト (通常は永続的) と多数のサービス オブジェクト (複数のドメイン オブジェクト間で操作を調整するために存在します) で構成されます。実際のアプリケーションでは、通常、ドメイン オブジェクトの永続性を管理するデータ レイヤーがあり、さまざまな方法で分割されている場合があります。

ビューが必要とする入力データを「API」と考えることも役立つ場合があります。互換性のあるデータを提供することでその API を満たすのはコントローラーの仕事です。コントローラーは、その逆ではなく、どのタイプのデータがビューを満たすかを知る必要があると考えてください。

于 2011-09-03T19:18:19.403 に答える