Hibernate的reference的副标题叫做：符合Java惯例的O/R 持久化，这揭示了目前三层结构的重大问题，就是三层的不统一。到目前为止，仍然难于在web界面上实现C/S模式中"master-detail"，"lookup"的快捷的用户交互。
目前常见的web application的结构，包含web browser/application server/database。database占据主流的仍然是经典的E/R模型，这个模型是基于行集的，因此在vb/Delphi/power builder的实践中，data source/table set都是基于行集的，odbc/jdbc driver也都是基于行集的。view层的DbGrid也是基于行集的，和Entity模型对应得非常好，开发简易直观，相信这是C/S模式得到迅速推广的重点原因之一。“master-detail”,"lookup"都是C/S模式下极为常见和直观的关联模式。
但本质上，Object pascal/java都是面向对象的。在此，就出现了一次重大的不统一：OO vs E-R。出现的解决方式就是EJB和O/R mapping 工具。EJB的entity bean是早期的entity封装形式。但是和现在以hibernate为代表的先进工具（对POJO执行持久化）比较起来，在OO与ER的对应上显得粗笨而难于使用。在这些工具中，代表OO与E-R融合的最本质的功能则是继续树与表结构的对应关系。hibernate2支持整棵继续树与一个表对应、继续树中每个类与一个表对应两种基本的对应关系，而hibernate 3引入的join标记则更可以将二者融合，实现每个类可选与基类在同一个表中持久或者在新表中保存部分持久数据，可以说hibernate 3把这个对应的任务完成得非常出色。"master-detail","lookup"则对应hbm.XML这样的映射文件中的"one-many","many-one"关联。
database与java的融合完成之后，下一步，不可避免的就是现有的web client与服务器端代码之间的融合。从表面上看，web client大多采用Html/javascript完成，而服务器端采用java输出，二者是简单的命令/反馈的模型，这个模型从model 1发展到MVC的模型后，编写代码变得清楚，但是开发人员仍然发现，编写web app仍然不是一件简单的事情。struts/webwork仍然只是非常底层的基础，对编写客户端业务对象没有什么帮助。比如说,在服务器端java程序建模时，大家已经习惯用pojo分析订单/客户/产品，但是在编写web client时，struts/webwork都只能帮助你完成页面提交/反馈的流程，却不能帮助你分析客户端业务：新建订单时，选择了客户之后，判定此客户是否有足够的预收款，这样一个简单用例在程序员心目中的反映仍然是每个字段的input tag,每个页面post上来的model,以及如何用action的处理再次渲染下一个页面。
最大的问题，就是作为表现层的web client端代码与服务器端代码蕴含的语义脱节。具体表现在：
在采用struts/webwork这样的MVC结构的时候，通常不会考虑在客户端进行业务控制，比如由javascipt判定预收款是否足够。因此需要不断的多次页面刷新才能完成整个逻辑。
要解决此问题，通常可以采用把业务逻辑部分转移到客户端，以javascript + xmlhttp或javascript + web service,java applet/application,甚至采用Office平台(嵌入代码到Excel)完成整个业务逻辑。也有很多问题：
1，若要在客户端实现业务逻辑，可能客户端代码没有对应Pojo这样的基础object设施。javascript缺乏如interface这样的基础结构。excel方案在这点更加难于进行，因为整个开发涉及到的语言太多，造成开发难度加大，项目控制困难。
直接后果就是，难于在客户端代码中定义"master-detail","lookup"等关联。就算在项目规划中在javascript中定义pojo(plain old javascript object)及其关联，也难于利用hbm.xml这样的现成关联描述。
2，客户端基础设施难于进行界面元素绑定。在处理大量数据时，excel方案在此体现出杰出的优势，客户对内置程序的excel的接受程度非常高，但缺点是这种excel程序难于做到xmlhttp可以轻松做到的动态查询等特性。
3，客户端基础设施难于与服务器端进行交互。xmlhttp以及web service可选，但是在企业应用中其低下效率可能会带来服务器的压力隐患，降低性能和吞吐量。若excel方案，则同样面临着与服务器数据交互的难题。不管是xmlhttp方案还是application方案，都面临着抛弃struts/webwork重新实现request/response dispatch的要求。
4，客户端基础设施难于进行单元测试。有junit4js，port了junit 3.8.1，但没有成熟的stub/mock工具。excel方案在此几乎不可测试。
5, 客户端基础设施难于调试。javascript缺乏类似log4j这样的log工具(log4js http://www.petrusrex.com/Programmes/jslib.htm ;这样的工具还远没有成熟)，也难于进行断点跟踪。excel方案倒是有完整的vba环境。
6, 客户端基础设施运行效率低。javascipt/vba都是解释语言，难于实现复杂逻辑，其性能决定只能用它们进行细粒度的界面控制。
7，由于浏览器的分裂，造成语言的不标准，应用程序难以跨平台使用。在IE平台上可以使用behavior和eXPression这种类AOP的操作，却无法在mozilla中实现。
jsf方案有望成为备选方案，但是按照myfaces目前的情况，要实现更多的表现层控件，才能完成更复杂灵活的控制。
下面一次软件开发方式的突破，向前看，可能出现设计方式的突破，MDA是方向；另一个方向就是向后对具体实现的突破，在类似webapp这样的具体技术（除了webapp,application同样面临类似问题）上，对于是否能够把model的定义直接带入到表现层，JSF和.NET可能会有新一轮竞争
