1.2.6 不匹配的代价

要想全面的解决上述列表中的不匹配，需要耗费很多的时间和精力。根据我们的经验，在Java中，大概有30%的精力都消耗在书写SQL/JDBC以及处理二者的不匹配上面。尽管作出这样的努力，最终的结果却还是不尽如人意。我们曾经见到不少项目因为复杂的数据抽象层导致项目的失败。 最耗费精力的部分恐怕要属于建模了。虽然关系模型和面向对象模型都服务于同一个商业实体，但是二者建模的方法则相去甚远。当遇到这种情况时，通常的解决办法就是面向对象的建模者妥协，不断的改进自己的模型来适应底层面向关系的模型。 这种方法通常能取得成功，但是代价往往是丧失了一些面向对象的优势。请你不要忘记面向关系的模型是由关系理论支撑的。而面向对象没有如此的理论支撑。因此我们无法给出一个公式来解释如何在对象和关系之间进行匹配，也就是说我们不可能有一种文雅的方式来解决这个问题。 当然模型之间的不匹配仅仅是影响性能的一个重要因素而已。另外一个原因则出在JDBC本身。JDBC和SQL提供了一种面向命令的方式来把管理数据。一个结构化的关系至少执行3次操作（insert,update,select），而这些操作明显要耗费许多设计和实现的时间。而每个关系型数据库的dialect都不能改进这种状况。 最近流行的一种方式是通过结构化或者模式来解决模型之间的不匹配问题。因此，就有了实体Bean模型，DAO模式以及一些其他方法来处理数据访问。这些方法被前面讨论的大部分都留给了应用程序开发者。为了完成你对于对象持久化的理解，我们需要讨论应用程序结构以及持久化层在应用程序中的角色。