0

MVC フレームワークでフォームの送信をどこで処理するかについて考えていただけませんか? ロジックを処理するモデルを用意するか、コントローラで直接処理しますか?

これがデータベースにユーザーを作成する登録フォームであると仮定しましょう。

そのようなものにどのようにアプローチしますか？

私がそれを行う方法は、コントローラーでフォームデータを検証し、データを使用して User モデルを作成し、それをデータベースに保存することです。ただし、モデルが特にフォームデータを処理しているのを見たことがあります (コントローラーはフォームモデルをロードして $_POST データを渡します)、それが必要かどうか疑問に思っています

ありがとう

4

2 に答える 2

0

Struts 2(最高の MVC フレームワークの 1 つ) が典型的なユーザー登録を処理する方法を次に示します。

Registration Page --Submit-->
    Filter Dispatcher (Controller) --Struts-->
        Interceptor --Stack--> Validator --Passed-->
            Action (Model)
                --Invokes--> Service/DAO Layer --Persists--> Database
            Result <--returns-- Action
        JSP (View) (selected based on result)
    Interceptor (any post-processing)
Registration Success HTML

Servlets実際にはコントローラーを作成しないのとは異なります。を使用して宣言的にフレームワークを構成するだけStruts.xmlで、MVC フロー全体が構成どおりに調整されます。

はControllerInterceptor を介して検証を実行し、データベースに永続化するために事前入力および検証済みのデータ オブジェクトをモデルに渡します。

public class UserRegistrationAction {

    private User user = new User();

    public User getModel() { // Struts Callback
        return user; // automatically gets populated with validated values
    }

    // This will seem incorrect to someone used to Spring's setter injection but
    // Struts injects in reverse; pulls the model onto a ValueStack to inject properties

    public String execute() {
        // already validated; simply persist
        UserRegistrationService.getInstance().persist(getUser());
        return Action.SUCCESS;
    }
    ...
}

はい、コントローラーに検証を実装することは正しいです。

ただし、そうは言っても、データの処理は常にモデル自体で行う必要があります。Facebook の友達リストまたは GMail の連絡先リストをインポートするかどうかをユーザーに尋ね、同意して必要な詳細を提供したとします。

public String execute() {
    user.setContactsList(
        thirdPartyService.getInstance(getPartyCode()).fetchContacts(user.getAuthInfo())
    );
    UserRegistrationService.getInstance().persist(getUser());
    return Action.SUCCESS;
}

サード パーティ サービスで認証し、他の詳細をフェッチして User オブジェクトを更新する (永続化する前に) ロジックもモデルに含まれます。これは、これがビジネス ロジックを構成し、コントローラーの実装に使用するテクノロジ (サーブレット、スタット、Spring MVC) に関係なく、スタンドアロンの再利用可能なモデル クラスにカプセル化する必要があるためです。

したがって、理想的には、分野横断的な問題 (検証、認証、キャッシュなど) のみをコントローラーに分解し、コア ビジネス ロジックはモデル内に残します。

于 2013-04-28T16:56:14.737 に答える
-1

ここでは、関心の分離が重要です。そうは言っても、コントローラーはフォームデータを認識すべきではありません。実際、Controller は html フォームの概念をまったく持つ必要はありません。

モデルは、何らかのフォームを介して提供する予定の値をカプセル化する必要があります。コントローラーはモデルに対して操作を実行します (モデルからデータベースへのデータのロードなど)。

各 MVC フレームワークは、使用される規則がわずかに異なりますが、一般的な意味で、上記で述べたことは、どの MVC フレームワークにも当てはまります。

更新（あなたのコメントに応じて）：

いいえ、その反対です。フォーム データは、基になるデータ ストア (つまり、データベース) を挿入/更新するコントローラーに渡されるモデル/ビュー モデルによってカプセル化する必要があります。MVC は高速道路システムと考えてください。モデルはパスに沿って走る車で、コントローラーはトラフィックを管理します。モデルは通常、データ フィールドを格納する単純なオブジェクトであり、コントローラーはそのデータを処理します。モデル/ビュー モデルはデータベース データとは別のものです。モデルは、ビュー (プレゼンテーション レイヤー) に提示したいものです。データベースはビュー/モデル/コントローラーとは別のレイヤー/層ですが、コントローラーはモデルを基礎となるデータベースに変換する責任があります。

于 2013-04-28T16:13:56.043 に答える