public class Group { public int grouId; public String groupName； public Set users; //set of User }

这里为了简单表明含义，暂不采用getter/setter。

而User对所属的Group有一个引用：

public Group belongTo;

在这里，User.belongTo和Group.users就是一个一对多的关系。

在我们的数据类中，如何才能实现数据库的存取呢？就算是不考虑Group.users这个反向关系，光是User.belongTo就是一件头疼的事。如果我们在取出一个User对象时同时将其Group对象也取出来，可以保证不会在访问某个用户的组时得到一个null。不过这样有几个缺点：

1. 数据类的存取处理（JDBC）变得复杂，需要执行很多SQL读取才行，有时候只需要访问User的基本属性时浪费时间和资源；尤其是对集合型属性的预读取，更加可怕

2. 如果按这个逻辑，双向的关系处理变得危险，很容易陷入死循环，如果要避免，必须在类代码中加入一些特别的机制，也是很麻烦的事

3. 如果对象之间的关系是更复杂的情况下，比如三个、四个对象之间互相关联，那就是一场噩梦，对代码的编写和维护都异常艰难

于是，很多开发人员自然而然地退后一步，在User类中只保留一个groupId，并不保存Group对象，这样，可以将User.belongTo属性变成int类型，而另外写一个getter方法：

public Group getBelongTo() { return Group.findById(belongTo); }

而在Group类中，干脆将users属性去掉，只保留一个方法：

public Set getUsers() { return new HashSet(User.findBy("select … from USER where BELONG_TO=?",new Object[]{ new Integer(groupId) })); }

也许细心一点的读者已经看出来了，这里的几个方法都没有将SQLException捕捉，也没有在方法中声明，也就是说是有语法错误的，因为SQLException不是一个RuntimeException。不错，确实是这样，不过我们这里为了简单明了起见，省掉这些处理，以更直接清楚地表达意思。

这样，实际上，我们的对象关系包装已经名存实亡，在类的内部有很多用于访问所引用对象的复杂代码，这些已经违背了我们将对象关系保持的初衷。有些开发人员甚至不在类中保留访问关系对象的方法，而是在客户调用时再去访问另一对象类的读取方法，如：

… User user = User.getById(…); //对user对象进行一些访问，如显示其姓名等等 Group group = Group.findById(user.belongTo); //对group对象进行一些访问，如显示组名等等 …

在这样的代码里，实际上我们已经从根本上退回了关系数据库的出发点，这与直接访问数据表有多大区别呢？只不过是在表上面套了一层貌似面向对象的皮而已。不幸的是，这种方式还存在于很多应用之中。

从前面提到的这些面向对象包装的细节问题，我们可以看到这种传统包装方式的一些主要的缺陷：

Java数据对象(JDO)的前世今生(5)

3.1.1.1 数据库命名与对象设计命名的一致性问题

很多时候，我们兴致勃勃地设计好一个类图，并且经过评审之后，开始对它进行数据库包装，这时候，发现有些属性名在具体的数据库中与该数据库的关键字冲突，不能用作表名或字段名，必须在数据表设计时采用另外的名称，或者很麻烦地加上引号来使用。于是，写数据库处理代码的人有意见了，他必须很清楚地记得一个属性在类中是什么属性名，在表中又是什么字段名，在编写的类逐渐增多后，尤其是一个类经过历次变动之后，或者经过很长时间又需要改动，并去处理这些JDBC代码时，代码维护人员简单要发疯了！

3.1.1.2 对象的查询仍局限于SQL

这一点也是这种简单的包装方法最不能摆脱关系数据库的地方。上面也已经说过，一些命名冲突

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!