对于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)
但是,如何Role
使用Room和userDAO获取User的对象?我发现不适合执行以下操作:
user = userDao.getUser(userId)
user.setRole(roleDao.getRole(user.getRoleId)
第三个问题:将表列中带有_(例如role_id
)似乎是一种好习惯,但roleId
建议在Java中将其作为类属性。如果的结果@Query
,例如select role_id from...
,并与该POJOroleId
领域,将无法因此查询需求是select role_id as roleId...
得到它的工作。在sqlite的表/列名称中使用驼峰大小写是一种好习惯吗?
您想要的POJO可能可以看作是一种视图模型。通常,统一/链接实体和pojos是一个坏主意,因为您只是在为实体创建一个较长的可见性/范围,这在不必要的情况下可能会导致潜在的问题。
假设您有一个需要对数据进行不同可视化处理的客户端,例如,假设您有一个网站公开车辆数据,并且已使用metric
系统实现了所有功能,那么就距离而言km
,对于速度km/h
等等。现在,您的公司从英国获得了巨大的客户,他们希望您以imperial
格式提供数据。现在要做什么?可能会实施反序列化/转换过程,该过程将获取值并根据用户的上下文进行转换(无论它们是否正在使用metric
或imperial
系统)。如果您的实体和视图模型对象基本相同,可能会出什么问题?真是坏东西。您之间的联系确实很紧密,应该为客户端的序列化实现不同的getter,因为db..it可能会变得一团糟。
相反,如果将两者分开,则将拥有一个实体来处理数据库,这是具有小的可变系数的标准过程,另一方面,您将拥有非常可能需要频繁修改的视图模型。 ,毕竟这是最终用户的界面,这是可以预期的。
本文收集自互联网,转载请注明来源。
如有侵权,请联系 [email protected] 删除。
我来说两句