当前页面: 开发资料首页 → J2EE 专题 → 我来谈谈EasyDBO的持久化策略

我来谈谈EasyDBO的持久化策略

摘要: 我来谈谈EasyDBO的持久化策略

　　先说说我对EasyDBO的一些个人的看法，EasyDBO是一个超轻量级的目前只支持单表映射的持久化框架，超轻量意味着入手很简单，使用很方便，但注意它是单表映射，导致在处理一些映射关系的时候要做一些特别的处理。在这里我说一些个人在使用EasyDBO对一般持久化策略的愚见。

一对一

　　一对一关系要分为两种情况，一是主表对从表的映射。如Name(firstName, lastName, midNmae) 表和User表，因为EasyDBO只支持单表的映射，如果表的粒度过细，会导致极细的领域对象的产生，如Name对象的产生，而又需要为这些细粒度的对象创建CRUD方法，而且EasyDBO没有象Hibernate那样的自动的关联持久化操作，而且如果不使用Easyjf-dbo.xml来配置的话（即直接使用类实现IObject接口的话），你甚至不能在User对象中出现Name对象的私有成员申明。所以在这种情况下，最好把Name表和User表融合。二是大表和大表的映射，在这种情况下就只有使用外键关联的策略。但同样要注意，EasyDBO现在还不是一个完善的持久化框架，我认为很重要的一点就是离开了easyjf-dbo.xml的配置来持久化对象，如果直接使用implements IObject（而这是我认为最方便简单的使用途径，想必用惯了Hibernate转而使用EasyDBO的人都用这种感觉吧）你不能完整的使用OO，即不能在BBSDoc中出现private BBSDir bbsdir;而只能使用private String bbsdir_id。

一对多

　　一对多（多对一）通过上面的分析，可只在这种情况下，最好还是使用外键的关联（多的一方主动关联一的一方）。那么在领域类为一的一方中，不能出现XXXSet之类（如果使用配置文件除外）。这样实现的就是单向关联。要使用双向关联的话，就只能为一的一方添加一个Util类，使用Query方法来得到多的一方的List了。

多对多

　　多对多的情况是比较复杂的了。一般的情况是通过建立一个中间表来管理两对象的关系。在EasyDBO中就分两个情况了。先举个例子：比如User和Role，这是一个典型的多对多的映射关系，在用户权限管理模型中这种实现方法很普通。那么对这个多对多该怎么处理？首先还是要建立一个User-Role表，这个是必须的，其次就出现了两个情况，一，直接使用User-Role表。这种情况就是说不对User-Role表做任何处理，在UserUtil中建立一个List getRoles（）方法，在该方法中直接使用SQL语句从做一个两层的嵌套查询。这种方法还是不错，对于原来就使用JDBC的程序员很熟悉，但比较麻烦而且查找次数较多。另一个就是为User-Role表建立一个UserRole对象，这也是我推荐的做法。建立一个对象的意思不是说就是一个单纯的建立一个桥梁对象（我自己就这样叫那种为只起中间过度作用的表建立的对象），我就想能不能根据实际的情况利用好这个对象。比如在用户权限管理界面中我们会列出某个用户的所有权限或者列出属于一个权限组的所有用户只类的，那么我门就可以在User-Role表（即UserRole对象中）添加一些冗余字段，如userName, roleNmae等等来方便页面的合成操作，比如我门可以方便的使用# foreach ( $UserRole in $UserRoleList)… $!UserRole.userName等等来简化页面的编写，而且这样操作，查询数据库的次数会少很多，而如果使用第一中就比较麻烦了。但要注意的是不能过多的添加字段，毕竟这些是冗余的数据。

其他的一些

1 希望持久化的对象是真正的POJO而不是在Hibernate中常常出现的哑对象和DAO；
2 我自己感觉还是使用IObject接口比较简单，这样才更好的体现了EasyDBO的简单易用性，虽然这样有些幅面缺点。


↑返回目录
前一篇: 用15分钟了解DaoZero:让它为你实现DAO接口
后一篇: Java EE 5 通过终审投票—JSR 224 技术规范