建议做法如下:
第一,写一个符合javaBean标准的实体类,类的属性名称和类型分别与数据库的字段对应,并加上无参构造方法和get、set方法;
第二,使用注解配置映射关系,用@Entity注解该类是一个实体类,用@Table(name = "表名")注解该实体类映射的表名,通过在每一个属性的get方法上添加@Column(name = "列名")注解该属性映射的列;
第三,配置主键,找出表主键映射的那个属性,用@Id在该属性的get方法上注解该属性为Id。(根据具体需要,可能还要做一些更详细的配置)
参考代码如下:
import javax.persistence.Columnimport javax.persistence.Entity
import javax.persistence.Id
import javax.persistence.Table
import org.hibernate.annotations.Parameter
/**
*
* 用户
*/
@Entity //说明该类是实体类
@Table(name = "USER")//说明该类映射的是表USER
public class TUser implements java.io.Serializable {
private String userID // 用户id
private String userName // 用户名称
private String loginName // 登录名称
private String password // 密码
private Integer status // 状态
private java.util.Date lastLoginTime // 上次登录时间
private java.util.Date regTime // 注册时间
@Id//说明该属性映射的是表USER的主键
@Column(name = "UserID", unique = true, nullable = false)
//该属性映射的是表USER的UserId字段,非空且唯一
public String getUserID() {
return this.userID
}
public void setUserID(String userID) {
this.userID = userID
}
@Column(name = "UserName")
public String getUserName() {
return userName
}
public void setUserName(String userName) {
this.userName = userName
}
@Column(name = "LoginName")
public String getLoginName() {
return this.loginName
}
public void setLoginName(String loginName) {
this.loginName = loginName
}
@Column(name = "Password")
public String getPassword() {
return this.password
}
public void setPassword(String password) {
this.password = password
}
@Column(name = "Status")
public Integer getStatus() {
return status
}
public void setStatus(Integer status) {
this.status = status
}
@Column(name = "LastLoginTime")
public java.util.Date getLastLoginTime() {
return lastLoginTime
}
public void setLastLoginTime(java.util.Date lastLoginTime) {
this.lastLoginTime = lastLoginTime
}
@Column(name = "RegTime")
public java.util.Date getRegTime() {
return regTime
}
public void setRegTime(java.util.Date regTime) {
this.regTime = regTime
}
@Override
public int hashCode() {
int prime = 0
prime += this.getUserID().hashCode()
return prime
}
@Override
public boolean equals(Object obj) {
boolean isEquals = false
if (obj != null && this.getClass() == obj.getClass()) {
TUser clazz = (TUser) obj
if (clazz.getUserID().equals(this.getUserID()))
isEquals = true
return isEquals
}
return isEquals
}
}
Java键值映射是指使用Map集合,来保存Key-value的一堆组合,一个key对应一个value,可以比喻成一间房子对应着唯一的一把钥匙。Map提供的键值映射机制,可以很好的保存各种数据,完成扩展。
使用Java泛型映射不同的值类型考虑一个例子,你需要提供某种应用程序的上下文,它可以将特定的键绑定到任意类型的值。利用String作为键的HashMap,一个简单的、非类型安全(type safe)的实现可能是这样的:
public class Context {
private final Map<String,Object>values = new HashMap<>()
public void put( String key, Object value ) {
values.put( key, value )
}
public Object get( String key ) {
return values.get( key )
}
[...]
}
接下来的代码片段展示了怎样在程序中使用Context :
Context context = new Context()
Runnable runnable = ...
context.put( "key", runnable )
// several computation cycles later...
Runnable value = ( Runnable )context.get( "key" )
可以看出,这种方法的缺点是在第6行需要进行向下转型(down cast)。如果替换键值对中值的类型,显然会抛出一个ClassCastException异常:
Context context = new Context()
Runnable runnable = ...
context.put( "key", runnable )
// several computation cycles later...
Executor executor = ...
context.put( "key", executor )
// even more computation cycles later...
Runnable value = ( Runnable )context.get( "key" )// runtime problem
产生这种问题的原因是很难被跟踪到的,因为相关的实现步骤可能已经广泛分布在你的程序各个部分中。
为了改善这种情况,貌似将value和它的key、它的value都进行绑定是合理的。
在我看到的、按照这种方法的多种解决方案中,常见的错误或多或少归结于下面Context的变种:
public class Context {
private final <String, Object>values = new HashMap<>()
public <T>void put( String key, T value, Class<T>valueType ) {
values.put( key, value )
}
public <T>T get( String key, Class<T>valueType ) {
return ( T )values.get( key )
}
[...]
}
同样的基本用法可能是这样的:
Context context = new Context()
Runnable runnable = ...
context.put( "key", runnable, Runnable.class )
// several computation cycles later...
Runnable value = context.get( "key", Runnable.class )
乍一看,这段代码可能会给你更类型安全的错觉,因为其在第6行避免了向下转型(down cast)。但是运行下面的代码将使我们重返现实,因为我们仍将在第10行赋值语句处跌入ClassCastException 的怀抱:
Context context = new Context()
Runnable runnable = ...
context.put( "key", runnable, Runnable.class )
// several computation cycles later...
Executor executor = ...
context.put( "key", executor, Executor.class )
// even more computation cycles later...
Runnable value = context.get( "key", Runnable.class )// runtime problem
哪里出问题了呢?
首先,Context#get中的向下转型是无效的,因为类型擦除会使用静态转型的Object来代替无界参数(unbonded parameters)。此外更重要的是,这个实现根本就没有用到由Context#put 提供的类型信息。这充其量是多此一举的美容罢了。
类型安全的异构容器
虽然上面Context 的变种不起作用,但却指明了方向。接下来的问题是:怎样合理地参数化这个key? 为了回答这个问题,让我们先看看一个根据Bloch所描述的类型安全异构容器模式(typesafe heterogenous container pattern)的简装实现吧。
我们的想法是用key自身的class 类型作为key。因为Class 是参数化的类型,它可以确保我们使Context方法是类型安全的,而无需诉诸于一个未经检查的强制转换为T。这种形式的一个Class 对象称之为类型令牌(type token)。
public class Context {
private final Map<Class<?>, Object>values = new HashMap<>()
public <T>void put( Class<T>key, T value ) {
values.put( key, value )
}
public <T>T get( Class<T>key ) {
return key.cast( values.get( key ) )
}
[...]
}
请注意在Context#get 的实现中是如何用一个有效的动态变量替换向下转型的。客户端可以这样使用这个context:
Context context = new Context()
Runnable runnable ...
context.put( Runnable.class, runnable )
// several computation cycles later...
Executor executor = ...
context.put( Executor.class, executor )
// even more computation cycles later...
Runnable value = context.get( Runnable.class )
这次客户端的代码将可以正常工作,不再有类转换的问题,因为不可能通过一个不同的值类型来交换某个键值对。
有光明的地方就必然有阴影,有阴影的地方就必然有光明。不存在没有阴影的光明,也不存在没有光明的阴影。村上春树
Bloch指出这种模式有两个局限性。“首先,恶意的客户端可以通过以原生态形式(raw form)使用class对象轻松地破坏类型安全。”为了确保在运行时类型安全可以在Context#put中使用动态转换(dynamic cast)。
public <T>void put( Class<T>key, T value ) {
values.put( key, key.cast( value ) )
}
第二个局限在于它不能用在不可具体化(non-reifiable )的类型中(见《Effective Java》第25项)。换句话说,你可以保存Runnable 或Runnable[],但是不能保存List<Runnable>。
这是因为List<Runnable>没有特定class对象,所有的参数化类型指的是相同的List.class 对象。因此,Bloch指出对于这种局限性没有满意的解决方案。
但是,假如你需要存储两个具有相同值类型的条目该怎么办呢?如果仅为了存入类型安全的容器,可以考虑创建新的类型扩展,但这显然不是最好的设计。使用定制的Key也许是更好的方案。
多条同类型容器条目
为了能够存储多条同类型容器条目,我们可以用自定义key改变Context 类。这种key必须提供我们类型安全所需的类型信息,以及区分不同的值对象(value objects)的标识。一个以String 实例为标识的、幼稚的key实现可能是这样的:
public class Key<T>{
final String identifier
final Class<T>type
public Key( String identifier, Class<T>type ) {
this.identifier = identifier
this.type = type
}
}
我们再次使用参数化的Class作为类型信息的钩子,调整后的Context将使用参数化的Key而不是Class。
public class Context {
private final Map<Key<?>, Object>values = new HashMap<>()
public <T>void put( Key<T>key, T value ) {
values.put( key, value )
}
public <T>T get( Key<T>key ) {
return key.type.cast( values.get( key ) )
}
[...]
}
客户端将这样使用这个版本的Context:
Context context = new Context()
Runnable runnable1 = ...
Key<Runnable>key1 = new Key<>( "id1", Runnable.class )
context.put( key1, runnable1 )
Runnable runnable2 = ...
Key<Runnable>key2 = new Key<>( "id2", Runnable.class )
context.put( key2, runnable2 )
// several computation cycles later...
Runnable actual = context.get( key1 )
assertThat( actual ).isSameAs( runnable1 )
虽然这个代码片段可用,但仍有缺陷。在Context#get中,Key被用作查询参数。用相同的identifier和class初始化两个不同的Key的实例,一个用于put,另一个用于get,最后get操作将返回null 。这不是我们想要的……
//译者附代码片段
Context context = new Context()
Runnable runnable1 = ...
Key<Runnable>key1 = new Key<>( "same-id", Runnable.class )
Key<Runnable>key2 = new Key<>( "same-id", Runnable.class )
context.put( key1, runnable1 )//一个用于put
context.get(key2)//另一个用于get -->return null
幸运的是,为Key设计合适的equals 和hashCode 可以轻松解决这个问题,进而使HashMap 查找按预期工作。最后,你可以为创建key提供一个工厂方法以简化其创建过程(与static import一起使用时有用):
public static Key key( String identifier, Class type ) {
return new Key( identifier, type )
}