在 B/S 开发中最简单的一种开发模式是页面 + 逻辑处理，映射到技术上反应出来的有 Jsp+Jdbc ，在基于这类的实现中在 View 层也就是 jsp 页面上负责数据的显示、逻辑处理，结合 jdbc 完成数据的持久化，在小型的项目中，人们确实发现这种方式是最为方便的，但在复杂的项目以及需求不断变化的项目中，人们慢慢的发现这种方式造成了不少的问题，首先是调试的问题，想想在一个 jsp 页面中进行排错是多么的困难，其次是修改的问题，为了满足用户需求的一个小小的变化，都需要去改不少的页面，而且很多时候由于写的时间长了，自己都需要回忆很久才能想起是怎么回事，更不用说如果人员流动了会怎么样，同时还带来开发效率的问题，由于需要缺少足够的调试的支持，需要较为熟练的开发人员才能快速的完成，对于一般的人员来说需要一定的适应和学习过程，当然伴随而来的还有诸如修改界面的时候一不小心少 copy 了点代码什么造成的错，最大的问题可能还是重用的问题，通常会造成 N 多同样的代码在页面上 copy 来 copy 去的，总结下来在这种模式下有几个比较重大的问题就是:

　　1、 调试问题。

　　2、 维护问题，显示和逻辑处理在一起导致了修改显示的时候较为困难，至于修改代码则因为之前的调试问题导致了困难，同时由于逻辑均在页面上后期接手人员需要一段时间去理解。

　　3、 代码重用性问题。

　　但同样它还是存在优点的，那就是可以很快的上手，但由于调试和维护性问题确实太大了，所以在现在也是基本不再采用这种方式了。

　　Jsp+JavaBean

　　在经历了 jsp+jdbc 阶段后，开始考虑怎么样去解决上面三个问题，这个时候就诞生了诸 JSP+JavaBean 这样的技术体系，在这个体系中由 jsp 页面负责显示以及接收页面请求，并调用相应的 JavaBean 来完成逻辑处理，在获取其返回的处理数据后转到相应的页面进行显示。在这样的技术体系中，由于逻辑是由 JavaBean 来完成的，可以对其进行调试了，代码的重用性一定程度上也得到了提高。刚开始的时候用这样的技术体系确实发现比以前用 jsp+jdbc 爽了很多，但随着用多了，慢慢又发现了问题，那就是在页面中需要编写对于页面请求数据的获取，还得根据请求去调用相应的 javabean ，并根据 javabean 的处理结果转入相应的页面，这同样造成了修改的麻烦，毕竟是去页面上修改这些逻辑，总结下来在这种模式下有比较重大的问题就是:

　　1、 代码重用性以及维护性问题。但这里的代码重用性问题和 jsp+jdbc 的就不同，在逻辑处理部分现在已经可以重用了，但现在在各个页面就不得不重复的写获取页面请求的参数、相应的调用 Model 、根据 Model 的处理结果转发页面，这样的话就导致了在改的时候需要到处去找，造成了维护的复杂。

　　2、 系统结构不清晰。毕竟仍然是在页面控制整个响应页面事件的处理流程，这个时候就造成了很多页面中出现完全相同的 jsp 代码，而且控制代码在页面，仍然是不便操作，例如对于 JavaBean 的调用等，而且由于获取 javabean 的数据需要转发的缘故，其实通常就是在最终的显示页面上加上上面的控制事件处理流程的代码，并没有真正的做到显示和处理的分离。

　　同样，它的优点在于分离了显示和业务逻辑处理，增强了可调试以及维护性，而且也是很容易上手的，对于小型项目来说仍然是可选的方案之一。

　　基于 MVC Framework

　　在经历了上面的 Jsp+JavaBean 后，我们发现其实现在最需要的就是在 jsp 、 javabean 之间能有个东西自动完成页面请求数据的封装、根据请求调用相应的 javabean 、同时根据 javabean 的处理结果返回至相应的 View ，有了这样的思想后，发现 smalltalk 中的 MVC 思想很适合这种场景，于是便在 Java B/S 开发中引入了 MVC 思想，在这里也简单的介绍下 MVC 思想， MVC 强调 View 和 Model 的分离， View 所面对的是 Controller ，由 Controller 负责与 Model 进行交互， View 只负责显示页面以及显示逻辑的处理，显示逻辑指的是诸如第一行要显示蓝色、第二行要显示红色这样的显示方面的处理， Controller 负责接受页面请求，并将其请求数据进行封装，同时根据请求调用相应的 Model 进行逻辑处理，在 Model 处理后返回结果数据到 Controller ， Controller 将根据此数据调用相应的 View ，并将此数据传递给 View ，由 View 负责将数据进行融合并最终展现。 MVC 带来的优点很明显的体现出来了，基于一个这样的 MVC Framework 的话开发人员可以按照一种固定的模式进行开发，规范了整个开发过程，提高了质量以及系统结构的清晰性，并由于保证了 View/Model 的分离，使得一个 Model 可以对于多种显示形式的 View ，需要的仅仅是去改变 View 和 Controller 。

　　按照 MVC 思想，最容易想到的实现方案莫过于 jsp+servlet+javabean ，在这里面 jsp 对应着 View ， servlet 对应着 Controller ， javabean 对应着 Model ，因为采用 servlet 可使用 servlet container 已经封装好的页面数据请求对象 HttpServletRequest ，这样就省去了自己封装页面请求数据的工作，作为 Controller 同时还需要承担根据请求调用对应的 javabean ，最简单的做法无非就是在 Servlet 中直接根据某种逻辑 ( 诸如反射或接口 ) 调用相应的 bean 进行执行，之后将 HttpServletRequest 、 HttpServletResponse 作为参数传入 javabean 进行处理， javabean 从 HttpServletRequest 中获取请求数据，将返回的结果数据放入 HttpServletResponse ，整个过程结束后继续由 Controller 接手进行处理，这个时候作为 Controller 的 servlet 将根据处理的结果返回相应的页面，在这个模型使用时人们慢慢的发现了一个问题，那就是随着 jsp 、 javabean 的变化造成了 controller 的不断修改，需要修改其中调用相应 javabean 以及转发相应页面的部分，为了解决这个问题，首先想到的是应该分离根据请求调用相应 javabean 的步骤，这个时候采用了设计模式中的 front controller+application controller 的方法， front controller 负责接受页面请求并进行封装，同时将此数据对象传递至 application controller ，由 application controller 来负责调用相应的 bean ，这样的设计其实都是遵循着一个设计原则，就是职责单一，通常实现 application controller 的模式是 Command 模式，在这种情况下 MVC Framework 的结构体系就演变成了 view+controller(front+application)+model 。

　　在完成了上述演变后慢慢又发现了一个问题，就是 model 依赖于了 httpservletrequest ，这样造成的一个问题就是没法测试，仍然要不断重启服务器来测试，当然与此同时的发展是 model 层的细化，细化成用于响应页面请求的 action Layer+Domain Model Layer+Persistent Layer ，在这里不去讨论后面层次的问题，因为作为 MVC Framework 它并不管你 Model 层是怎么个处理流程的。

　　慢慢也发现了另外一个问题，那就是变化经常要影响到 controller 的修改，于是便引入了采用配置文件的解决方法，编写 action 的配置文件，在配置文件中控制根据 action 的返回结果转入相应的 View ，这样的话在将来需要改变的时候只需要去改变这个配置文件就可以了，保证了 Controller 的稳定，这是典型的设计中的重点考虑因素，分离变化和不变化的，让变化造成的影响最小。

　　但在引入了上面的配置文件后，慢慢又发现了问题，那就是手写配置文件总是容易出各种各样的问题，这个时候采用图形化的界面来生成配置文件的想法又有了，这也就造就了 page flow 的诞生，当然，这只是 page flow 的一小部分功能。

　　当然，随着MVC的发展，也带动了其他相关技术的发展，如异步请求/响应模式(ajax、amowa，^_^)等。

　　在 MVC 思想接受后开源界的 MVC Framework 也是如雨后春笋般的冒出，比较知名的有 struts 、 webwork 、 spring mvc 等，这些 MVC Framework 基本都已经做到了上面提及的 MVC 思想演变的一些需求，当然，即使现在的 MVC Framework 是做到了，但在使用这些 MVC Framework 的时候我们通常又开始违背 MVC 思想的基本要素，就是保持 View 仅仅是 View 的原则，所以我比较推荐在 View 使用 Velocity 这之类的东西作为 View ，尽量保持 View 的纯洁性，任何技术的发展都是循序渐进的，不站在那个高度的时候是不知道前面还有什么样的高山的，那么现在我们缺少的又是什么呢?现在的 MVC Framework 中还存在着什么不足呢?这是值得我们思考的。

   A、什么时候使用Hibernate?

   Hibernate是业界一个比较成熟的流行的O/R Mapping框架.
   说它成熟,因为他提供了一个O/R Mapping产品最主要的功能,比如数据库映射、连接池管理、事务支持等等,更重要的,它提供了对多中数据库产品的支持.也许,O/R Mapping和多数据库支持更能够吸引开发者的眼球.
   说它流行,因为太多的人使用了,不论是从实用开发的角度出发,还是从研究的角度出发,甚至是从赶时髦的角度出发.相对于没有自己的数据持久层开发能力的开发者角度看,hibernate的确能够为他们带来开发效率的提高,改进软件架构.

   那么在什么情况下选择使用hibernate来构建自己的数据持久层呢?

1、自己没有数据持久层开发能力

这个当然勿庸置疑了.hibernate提供了一套成熟的模型,能够在短时间内构建适合业务需求的数据持久层.当然,前提是要对hibernate有基本的使用开发能力.

2、对JDBC底层开发不甚熟悉者.

hibernate封装了对JDBC底层的调用,统一了对不同类型数据库系统的支持.在缺乏对JDBC底层调用的了解之前,使用Hibernate可以事半功倍.

3、团队开发中统一持久层开发.

我们把hibernate称为O/R Mapping开发框架.既然是框架,那么如果团队中的成员对这个框架比较熟悉的话,那么可以统一团队的开发,减少沟通的频率,促进协同开发.

4、自己开发的数据持久层不能满足业务需求.

如果缺乏对JDBC的了解和数据持久层开发的经验,可能自己开发的数据持久层会慢慢的不满足业务需求.比如在数据缓存、连接池管理、多数据库支持等等方面.hibernate在上述方面有比较出色的表现,自然在不影响业务开发的前提下可以考虑采用.

5、希望你的产品不依赖于某种特定的数据库.

B、如何设计适用于多种类型数据库的通用产品呢?

如果你开发的是一款通用产品,使用了MS-SQL2000数据库,可能某一天你的客户会要求你将产品迁移到Oracle,理由很简单--客户原来就有购买Oracle数据库,不希望再增加数据投资了.但是你只能很遗憾的告诉他,你的产品只能使用MS-SQL2000数据库.无疑,你将可能失去一个重要的准客户.

那么,如何设计适用于多种类型数据库的通用产品而不是提供多个产品版本呢?

由于JDBC本身就是数据库独立的,即不依赖于具体的数据库类型.因此,我们可以从以下几方面进行把握:

1、尽量使用标准通用的SQL语句.

2、尽量上不使用各数据库方言和某种数据库特有的函数或者数据类型,尽量通用.

3、将配置参数保存在一个properties文件中.

4、利用Configuration.setProperties(Properties pro)方法载入配置参数文件,而不是采用Configuration.configuration()默认自动载入hibernate.hbm.xml配置文件.

C、选择合适的获得JDBC连接方式

假设已经配置了数据库表映射文件并得到了SessionFactory:

Configuration cfg = new Configuration();

SessionFactory sessionFactory = cfg.buildSessionFactory

在这里我们讨论一下三种获得JDBC连接的方式:

1、用户自己提供JDBC连接:

java.sql.Connection conn = datasource.getConnection();

Session session = sessionFactory.openSession(conn);

这种方式允许用户程序自己来管理JDBC连接.不过同一个连接上不能打开两个并行的session.

2、使用Hibernate默认的JDBC连接方式:

通过一下四种方式设置JDBC连接参数:

a、传递一个java.util.Properties到Configuration.setProperties();

b、在classpath目录提供一个hibernate.properties配置文件;

c、在hibernate.hbm.xml中包含JDBC配置参数;

d、通过java -Dproperty=value指定系统属性.

之后使用Session session = sessionFactory.openSession()获取JDBC连接.这个时候所有的hibernate属性和约束都保存在net.sf.hibernate.cfg.Environment中.

3、使用JNDI获得JDBC连接:

这个应该可以归到2上,不过比较特别,独立出来.

使用JNDI获得JDBC连接要依赖于Application Server的JNDI特性,不过可以将JDBC的管理交给Application Server去完成.采用这种方法获得的JDBC自动集成Application Server的容器管理事务的特性.不过如果更换容器之后都需要重新部署容器的JNDI.

D、什么时候POJO需要实现equals和hashCode方法?

当你需要混合使用POJO的时候,比如使用set,必须考虑重载equals和hashCode,特别是在两个不同的session装载POJO.Hibernate只在单个session保证JVM鉴别,而且是使用Object默认的equals和hashCode,如果没有重载equals和hashCode.

在通常情况下,重载equals和hashCode方法,我们会在方法中比较POJO的标识关键字.不过,在hibernate中,如果这个POJO还没有持久化,那么POJO的表示关键字是不存在的.所以,我们会采用商业关键字相等的原则来判断两个POJO是否相等.

E、如何合理利用hibernate提供的数据二级缓存功能:

1、惰性载入机制

2、接口代理机制

3、隐式多态机制

1、支持如下主流数据库类型:

MS-SQL(MSDE)、Oracle、DB2、Sybase

2、更换数据库系统不需要手工修改配置文件和拷贝数据库驱动程序,通过提供的软件工具可以实现可视化修改.

3、在软件系统安装或者第一次启动运行的时候配置,一次性配置,处处运行.

原则:

1、尽量使用标准通用的SQL语句.

2、基本上不使用各数据库方言.

3、下面以Hibernate为例,探讨如何实现上述需求.

a、将配置参数保存在一个properties文件中.

b、利用Configuration.setProperties(Properties pro)方法载入配置参数文件,而不是采用Configuration.configuration()默认自动载入hibernate.hbm.xml配置文件.