Question

Room仍然是新手，虽然我发现的大多数教程都与简单的表和CRUD操作有关，但我仍坚持不断发展。

让我们看一下这个示例结构。

用户实体

@Entity(tableName = "users")

public class UsersEntity{
    @PrimaryKey(autoGenerate = true)
    private long id;

    @NonNull
    private String name;

    @NonNull
    private long roleId;
}

角色实体

  @Entity(tableName = "roles")

    public class RolesEntity{
        @PrimaryKey(autoGenerate = true)
        private long id;

        @NonNull
        private String name;
    }

第一个问题：应该扩展Entity对象以替代POJO吗？还是将实体和POJO作为单独的类？

从“房间”设置中扩展，我看到用户POJO的方式是：

public class User{
   private long id;
   private Role role;
}

基本上，如果用户将来自Web服务的json响应或用户在应用程序的输入字段中输入，则此设置均应起作用。

但是，这引发了第二个问题：如何插入和检索用户信息？似乎可以插入，因为可能会出现

userDAO.insertRole(userId)

但是如何通过使用Room和userDAO获得User的Role对象？我发现不适合执行以下操作：

user = userDao.getUser(userId)
user.setRole(roleDao.getRole(user.getRoleId)

第三个问题：表列带有_（例如role_id）似乎是一个好习惯，但是在Java中建议将roleId作为类属性。如果实例@Query的{{1}}和带有select role_id from...的POJO的结果将失败，那么查询必须为roleId才能正常工作。在sqlite的表/列名称中使用驼峰大小写是一种好习惯吗？

Answer 1

您打算作为POJO使用的东西，可以看作是一种视图模型。通常，统一/链接实体和pojos是一个坏主意，因为您只是在为实体创建一个较长的可见性/范围，这在不必要的情况下可能会导致潜在的问题。

假设您有一些客户需要对数据进行不同的可视化处理，例如，假设您有一个网站可以显示车辆数据，并且您已经使用metric系统实现了所有操作，那么对于距离，您拥有{{1 }}，用于速度km，依此类推。现在，您的公司从英国获得了巨大的客户，他们希望您以km/h格式向他们提供数据。现在做什么？可能实现反序列化/转换过程，该过程将获取值并根据用户的上下文（无论它们使用的是imperial还是metric系统来转换它们）。如果您的实体和视图模型对象基本相同，可能会出什么问题？真是坏东西。您之间的联系确实很紧密，应该为客户端实现不同的getter进行序列化，因为db..it可能会变得一团糟。

相反，如果您将两者分开，则将拥有一个实体来处理数据库，这是具有小的可变系数的标准过程，另一方面，您将拥有非常有可能使用视图模型的视图模型。毕竟，这是最终用户的界面，因此需要经常进行修改。

处理实体和Pojos

1 个答案: