所谓数据驱动型的网站，其实就是常见的MIS系统在B/S形式下的实现。B/S模式在90年年代末大量出现的时候，其主要特征是Page-Based，也就是基于页面的。因为Html技术的网站本身是一张一张的页面组成的内容展示工具。对于MIS系统的比较复杂的高速交互式的操作，用本质上不是非常兼容。
从1995年到2005年的十年间，所有人都在与两大不兼容问题进行斗争，编写了无数无任何意义的代码，尤其是以Java最为甚。
第一个不兼容是ORM，也就是关系对象映射，95年以后，是面向对象程序设计大行其道的时候，Java也是标榜自己的原生的面向对象特质。但是，MIS系统操作的数据，是关系型数据库，其存储在数据库中的数据形式，是以表为形式的。所以绝大多数Java的项目，都将表直接映射为一个对象，对象里面只有get和set方法，这种对象呗成为POJO(Plain Old Java Object)，也就是贫血的老旧的Java对象,然后所谓的海量的DAO代码，不断的将各种表对应到POJO的对象当中。
后来出现了hibernate，通过xml配置，将对象和表进行了所谓的快速绑定。
但是hibernate存在两个问题，导致其使用非常受限。
首先hibernate的性能极差，使用hibernate的Java项目的性能会下降十倍左右，而且hibernate采用反射的方式构造POJO对象，POJO对象的特征是大量的产生大量的销毁，在一个用户一次网页的数据访问过程中，至少会生成10个POJO对象，如果一个500并发的小型业务系统正常运行1个月，将会用反射创建13亿个POJO对象。而Sun的Java虚拟机存在一个特性，其系统容纳的类的信息，在运行时，都放在permGen内存区域当中，有一个类，占据permGen一点数据，而在反射的时候，其实是现场编写了一个新的类（反射代理类），所以每一次反射，就会占据PermGen的内存的一小块空间。假设一个代理类只占一个字节，13亿个对象，也就会永远占据1.3G的内存。虽然可以通过调整JVM的permGen内存大小的方式，保证系统能多运行一会，但是在正常的业务系统中，平均1到2个月的宕机几乎是无法避免的。
其次，hibernate的关系映射并不完全覆盖掉所有的关系型数据库提供的功能，很多关系型数据库提供的功能，在hibernate的对象关系型映射，其中并没有充分的实现，很多复杂的SQL几乎不可能改写为hibernate的HSQL和关系映射。所以不可避免的在存在hibernate的系统中，容纳非常多的jdbc直接读写数据库的代码。容易造成事务性和代码维护的困难。
第二个不兼容，也就是业务系统的需求和网页这种交互形式的不兼容。传统的html网页，并没有提供充分的交互能力，所以采用B/S模式的MIS系统，缺乏真正的得到用户赞赏的案例，在日本，大家用的Excel实现业务的功能，在欧洲，SAP的客户端软件大行其道。用网页做的业务系统，经常被诟病为打开慢，没反应，不人性化。根本原因就是交互的时候页面通过form不断的提交，刷新，不符合人们心里对软件系统的预期。
在客户端里面轻松实现的Excel式表格操作，Word式排版，公式，复制粘贴，报表，打印调整，实现都非常困难，实现了也只是一个样子，应付用户的初期审查。
这次的项目，我们也是针对这两个问题，奋战不息。
其实，在解决这个矛盾的过程中，其实微软的C#，早在2003年就找到了相对正确的解决方案。
微软基本思路如下：
不对面向对象进行生搬硬套，用ADO对象的DataSet来处理表，表就是表，没有必要转化为对象进行处理。
交互方面，采用大数据量的view_state隐藏字段，尽可能的本地响应用户的操作，尽量模拟用户在桌面端的体验。但是由于当时还没有Ajax技术，这种提升效果有限。
而Java社区，没有很好的处理好这两个问题，导致很多Java的市场份额，被PHP占据。PHP主要就是在数据绑定方面，直接将表的暴漏给前端，然后用模板的方式进行解析和组装。交互方面基本放弃了MIS系统的开发，全面转向内容型的互联网服务。
项目的模式
Java的项目目前主要有三种开发模式
1.采用三层架构，用Spring+ORM中间件+前端框架实现业务系统。这种开发模式的有点是代码非常面向对象，便于管理，容易阅读，功能清晰。缺点是性能极差，学习成本比较固定，上手需要3个月左右，需要比较系统的培训，受限于系统特性，导致功能比较弱，用户使用感觉不流畅。对于事务管理方面，粒度太低，要么就都加事务，要么都不加，虽然可以配置但是配置文件非常复杂。大多数Java的项目都是如此开发的，多数都实际上失败，缺乏用户的足够好评。
2.采用Servlet，Servlet直接使用JDBC，因为原生的JDBC进行ORM非常复杂，会产生大量的冗余代码，但是开发成本低，学习曲线低，开发的系统非常稳定。实现的功能往往比较强大。少数成功的Java项目，都是采用这种模式进行开发的。
3.第三种模式，参考微软的思路，不采用面向对象来映射数据，而是直接将表暴漏给前端。这种的问题是只适合实现内容管理的MIS系统，而且Java社区，对此思路嗤之以鼻，因此几乎没有这种实现组件，如果用Java实现此模式，就要实现一个Java版本的.net Framework的数据连接组件部分。
这次的项目，主要选择了第二种模式，项目启动阶段，主要考虑到我们人员对Java了解不是很多，如果直接用第一种模式，需要大家先放下所有工作，去从Struts，Spring，Hibernate进行学习，如果学习到独立开发阶段，乐观至少需要1到2个月的时间。学习的主要内容是配置文件的思路。而且在开发时，由于大家都依赖于两个配置文件。在协同过程中Struts.xml, applicationContext.xml不可避免的发生冲突。
第三种模式，走不通是是因为开始的时候需求并不明确，不能完全确认这个系统就是对表的操作，而且实现ADO的组件难度非常大，项目风险非常高。
因此，选择了麻烦而又稳妥的第二条道路。
来源：oschina
链接：https://my.oschina.net/u/1378360/blog/224000