【问题标题】:Play framework 2: one model approach播放框架 2:一种模型方法
【发布时间】:2012-08-14 20:35:57
【问题描述】:

问题:

当使用 play framework 编程时,我觉得我遇到了与过去很多次相同的问题,即 创建多个相同类型的模型,只是因为我想添加、更新或在不同的用例中使用关于特定模型的不同数据。

让我解释一下,让我们考虑一个示例,其中我有 2 个不同的视图:registerlogin

我会有以下用户模型:

/**
 * 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 字段来确认用户输入的密码是否正确,所以我会将其添加到用户模型中:

@Required
@Transient
public String repeatPassword;

好的,那么我将扩展此模型以重复密码确认检查,以便在提交表单时更正我的“自动”验证,如下所示:

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

所以即使现在我也会有一个额外的属性repeatPassword,它不会保存在数据库中,而是在注册时使用。

问题#1:我们的模型开始逐渐变得混乱。

在登录的情况下:我想使用相同的模型,因为它是一个正在尝试登录的用户,对吧?但我只需要电子邮件、密码而不是所有字段。

问题 #2: 我的 User 模型不能用于登录,因为它已经定制为在注册中使用 - 我需要移动 repeatPassword 和 validate() 方法来分离 UserRegistation 模型,加上重复firstName lastName 等字段或在注册中使用 User 和 UserRegistration 模型混合,并将两种不同的表单呈现到相同的注册视图 = 令人困惑。

问题#3:我的登录页面不能使用用户模型,因为它有注释,如果我不添加所有必要的字段,如名字、姓氏等。我会出错。同样,我需要创建单独的 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 个不同的模型来代表用户,其中一个被持久化到数据库中,另外两个用于在我们在模板端完成登录和注册功能时验证错误。

所以我的问题是:我到底应该如何开始解决这个烂摊子?代码复杂性正在快速上升:) 我是否应该创建单独的 models.template 和 models.database 包,其中模板模型只是注释中的模型,并且在没有错误的情况下我开始填充真实模型,然后将其信息保存或更新到数据库?我迫切需要你们的答案,我们可以制作一种模型方法吗? 提前。

【问题讨论】:

    标签: validation model-view-controller model playframework playframework-2.0


    【解决方案1】:

    我将从头开始:您不需要为 changing passwordloggin-in 使用整个模型(也不需要创建单独的“非持久”子模型),尽管Form<YourModel> 在填充大型对象时很有用,您可以避开它们并依靠常见的DynamicForm

    在这种情况下,它当然不会使用在模型字段中添加注释的constraints,但您可以手动验证它们。

    例如:在注册表单中,您可以检查@Required 字段是否存在,例如emailfirstNamelastName(提示:同时添加MinLengthMaxLength 约束),但是 你应该从password 字段中删除@Required 注释。

    接下来检查表单是否没有任何错误后,您可以检查passwordrepeatedPassword 是否相同并且它们相同,您还可以添加一些个人(建议)@ 987654337@ - 模型中的注释很可能是不可能的。

    在记录表单的情况下,事情变得更加容易:使用DynamicForm 数据只需尝试使用给定的password 查找现有的password,如果结果为null,则意味着用户不存在或@987654342 @ 是无效的。

    最后,提示:有现成可用的全栈authentication and authorisation module available for Play 2.0 by Joscha Feth(我非常支持这个解决方案。)

    【讨论】:

    • +1 for auth 模块,我之前尝试过securesocial,但它需要太多的编程来适应我的情况(我觉得它太依赖于它自己的实现)。但是对于模型来说,我希望我们可以使用注释和/或 validate() 方法将验证保留在模型中。我知道所有内容或其中一些也可以在控制器端进行检查,但是我们已经验证了在两个不同的地方。而且我不确定这是否比创建具有少量属性的几个子模型更好或更差:/但如果我没有正确理解您,请澄清。
    • 我认为带有注释的子模型和控制器内验证之间的选择 - 属于你。恕我直言,您什么时候将主模型划分为大型子表单 - 您可以使用其他模型,如果您只是更改密码,那么在控制器中使用简单检查确实更快更干净。
    • 是的,我会接受你的回答,我会决定根据手头的视图使用子模型和控制器验证,而模板模型可能是不同的包(而不是将它们隐藏在控制器或普通模型中,如内部类)。所以,是的,也许有点 IMO 的事情,但尽管我们有约定,开发人员之间的代码可读性更高。
    猜你喜欢
    • 2013-05-10
    • 1970-01-01
    • 2012-07-20
    • 1970-01-01
    • 2014-07-23
    • 2013-04-17
    • 2014-05-28
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多