这几个月,我都在用JPA做练习,除非就几个表,我才用JDBC直接访问。使用映射框架能够节省很多代码量,首先那些烦人的数据库表的字段再也不用一个个的写了。确实是映射框架能极大的提高开发效率,这在自己的实践中也证实了。不过前提是IDE的代码生成,如果没有IDE的代码生成,那也是比较麻烦的。
在使用的过程中,自己都是建好外键,尤其,我写一个OA时,使用了powerdesigner设计了下数据库,然后建立外键,然后生成SQL语句,最后导入数据库,接着借助IDE生成实体类。
第一 那些外键就会以多对一的形式体现出来,此时一方引用着唯一的另一方,而另一方表现为一个集合的方式引用前者,但是很多时候,我查询的数据都是带很多条件的,它这个一对多引用的集合,很多情况下,并不会用。当然默认情况下它是延迟加载的,也就是直到访问时才去真正从数据库里查询。
反过来,如果不使用外键的话,自己去设置自己需要的集合就可以了,此时通过一定的数据库访问方法获得,并设置其值。
第二,在页面中,如果显示数据,借助外键,只需查询一个对象就可以了 就是用find方法,然后集合可以直接在页面用JSTL获得。但是有时候更新时,往往不同步,于是更新完后必须flush下,才行。
反过来,不使用外键,就不会涉及数据同步问题了,因为实体间关系靠程序自己分辨,而不用映射框架去映射。
第三,使用外键时,如果一个实体的集合字段的某个需要更新或删除时,尤其大量的操作这个实体的List时,List变了,提交后,自动同步到数据库,处理时能节省好多代码。
反过来,不使用外键,可就真需要自己去维护这些从属关系了,当然了也不是很麻烦。
第四,使用外键时,那些外键就以对象形式体现了,被引用主键的那个实体,必须查询出来后,才能set进入当前的实体,因此要多出好多查询,虽然,很多时候可以从缓存中拿到,而不是去数据库里现取,但总感觉很占用内存。
反过来,不使用外键,有ID字段的int值就可以set了,而不用查询出那个对象。
其实拿id构造一个对象也是可以的,因为这个时候真正需要的其实就是这个对象的ID字段,netbeans在生成实体类时都肯定有个带主键的构造器。从另一方面讲,之所以查询一下,可以确认该对象还存在否,如果不存在,可以确认目前合理不合理。
最后,JPA在初始化时cpu会100%几秒,只要修改了类文件后,涉及到访问数据库的操作,就会发生。感觉sun出品的框架都很重量级,尤其EJB更是如此。不过JPA真的很方便快捷。当然了这应该算作是hibernate的功劳,是hibernate引领了如此美妙的ORM。
综上考虑,我下一步也不使用外键了,这样不用考虑什么多对多、多对一关系,好像更像封装的JDBC了,呵呵!
不知道效果如何,前几天下了JSPRun的一个论坛项目,它里面就是没用外键,hibernate的映射配置文件非常简洁,就是和数据库的直接映射,然后具体的逻辑关系全在代码中自己维护!
今天写到这,明天开始体验!