1

問題：

Play フレームワークでプログラミングするとき、同じタイプの複数のモデルを作成している過去に何度も同じ問題に遭遇しているように感じます。これは、異なるユース ケースで特定のモデルに関する異なるデータを追加、更新、または使用したいからです。 .

説明しましょう。登録とログインという 2 つの異なるビューがある例を考えてみましょう。

次のユーザーモデルがあります：

/**
 * Example User class (simple annotations for demo purposes).
 * 
 */
@Entity
public class User {

    @Id
    public Long id;

    @Required
    public String email;

    @Required
    public String password;

    @Required
    public String firstName;

    @Required
    public String lastName;

}

登録の場合: register.scala.htmlに対応するすべてのフィールドがあります: email、password、firstName、lastName - 登録時にそれらすべてが必要になるからですよね?

しかし、repeatPassword フィールドを使用して、ユーザーがパスワードを正しく入力したことを確認したいので、これを User モデルに追加します。

@Required
@Transient
public String repeatPassword;

わかりました。このモデルを拡張して、フォームが送信されたときに「自動」検証を修正するために、パスワード確認チェックを繰り返すようにします。次のようにします。

public String validate() {
if(!password.equals(repeatPassword)) {
    return "Passwords doesn't match.";
}
    return null;
}
}

したがって、今でも、データベースには保持されないが登録内で使用される追加の属性 repeatPassword が 1 つあります。

問題 #1:私たちのモデルは少しずつ混乱し始めます。

ログインの場合:サインインしようとしているユーザーなので、同じモデルを使用したいと思いますよね? しかし、すべてのフィールドの代わりに、必要なのは電子メールとパスワードだけです。

問題 #2:私のユーザー モデルは、登録内で使用するために既にカスタマイズされているため、ログインで使用できません。登録内のUserRegistrationモデルと、2つの異なるフォームを同じ登録ビューにレンダリングする=紛らわしい。

問題 #3:ログイン ページで User モデルを使用できません。注釈が配置されているためです。firstName、lastName などの必要なフィールドをすべて追加しないと、エラーが発生します。繰り返しますが、ログインして仕事をしたいという理由だけで、別の UserLogin モデルを作成する必要があります。以下の例:

public class UserLogin {

    @Required
    public String email;

    @Required
    public String password;

    public String validate() {
        if(User.authenticate(email, password) == null) {
            return "Invalid user or password";
        }
        return null;
    }

}

非常に高速なので、ユーザーを表すためだけに 3 つの異なるモデルを用意します。そのうちの 1 つはデータベースに永続化され、他の 2 つはテンプレート側でログインおよび登録機能を完了するときにエラーを検証するために使用されます。

だから私の質問は、一体どうやってこの混乱を解決し始めるべきなのか? コードの複雑さは非常に急速に高まっています:)テンプレートモデルが注釈内のモデルのみである別のmodels.templateパッケージとmodels.databaseパッケージを作成する必要があります。エラーがない場合、データベースに情報を保存または更新する前に実際のモデルを埋め始めますか? 皆さんからの回答がどうしても必要です.1つのモデルアプローチを作成できますか? 事前にt​​hnx。

4

1 に答える 1

1

最後から始めます。changing passwordまたはにモデル全体を使用する必要loggin-inはありません（また、個別の「非永続」サブモデルを作成する必要もありません）。ただし、Form<YourModel>大きなオブジェクトを埋める場合は便利ですが、次のことができます。それらを避け、共通に依存するだけDynamicFormです。

このような場合はもちろんconstraints、モデルのフィールドに注釈を付けて追加することは使用しませんが、手動で検証することはできます。

例：登録フォームで、、、などの@Requiredフィールドが存在するかどうかを確認できます（ヒント：追加と制約もあります）が、フィールドから注釈を削除する必要があります。emailfirstNamelastNameMinLengthMaxLength@Requiredpassword

次に、フォームにエラーがないpasswordかどうかを確認した後、同じであるかどうかを確認repeatedPasswordし、それらが同一であるかどうかを確認することもできます（推奨）strength check-モデルの注釈ではおそらく不可能です。

ロギングフォームの場合は、これまでになく簡単です。データを使用して、既存のデータを検索してDynamicFormみてください。結果が、ユーザーが存在しないか無効である場合に限ります。Userpasswordnullpassword

最後に、ヒント： JoschaFethによるPlay2.0で利用できる、すぐに使用できるフルスタックauthenticationのauthorisationモジュールがあります（私はこのソリューションを大いに支持しています）。

于 2012-08-18T23:41:17.027 に答える