在jsp中调用javabean时不会用到的标记_Java Bean的前世今生（二）

为了抢夺当时炙手可热的VB市场，Java祭出Java bean，力图挽回一局。无奈微软的操作系统具有着无可替代的统治地位，再加上先发优势，java桌面开发终究未能撼动VB的领先地位，后来微软趁热打铁陆续推出c# winform、wpf等桌面编程技术，那是后话了。

既然在桌面端很难有用武之地，Java阵营决定在服务端尝试使用java bean，首先想到的是用来在jsp里封装业务逻辑，保存数据到数据库。比如jsp中有个user对象，包含了用户名userName和密码password属性，在后端可以建立一个与之相应的java bean，属性和jsp保持一致，这样就直接实现了前端和后端的数据映射，这就是JSP Model1。

JSP Model1在早期的小型项目中受到程序员的欢迎，但随着项目逐渐增大，一个项目中的jsp页面多达成百上千，这些页面又互相调用，项目发展成了一团乱麻，对于看重秩序的程序员来说，这简直就是灾难。于是Java bean再次进行了华丽升级变成Jsp Model2，这次引入了MVC的思想，jsp作为view，Servlet为Controller，Java bean就是Model。这样把业务逻辑、界面和处理过程做了分离，项目再次清晰起来。之后，基于此模型，发展出了Struts、SpringMVC等。

随着Java在“企业级应用”领域步步为营、攻城拔寨，面临的挑战也逐渐增多，诸如分布式、安全、事务、高可用性等等要求使得程序代码越来越重，也越来越难以维护。Java为了应对这些挑战，推出了J2EE规范，包括了数据库连接(JDBC)、远程过程调用(RMI)、消息服务(JMS)、事务管理(JTA)、收发邮件(Java mai)、命令和目录接口(JNDI)这些重要组件，而Java bean此时已经再次升级为了Enterprise Java Bean，简称EJB。此时这个小豆子早已破土而生，长成了一个大树。通过EJB，程序员可以将精力放到业务上，而那些事务、安全等重要但烦人的工作全部交给EJB就行了。

事情总是这样，新事物出现时，大家欢欣鼓舞，但真正落地使用后，各种弊端也开始逐渐涌现出来了。EJB太重了，而且为了满足其一系列的特性，性能问题也开始凸显出来。比如程序员要写一个SessionBean的实现，必须实现ejbCreat()、ejbActivate()等方法，但这些方法却根本没有用到。追求洁癖的程序员们难以忍受项目中出现这些莫名其妙的代码，于是一场复古的运动开始在坊间发酵。“We Want Plain Old Java Object”，不只是谁先喊出了这句口号，很快就受到了各地Java程序员们的热烈响应。

有需求的地方就会有人蠢蠢欲动，一个叫Rod Johnson的意见领袖发起了一场“winthout EJB”运动，试图要革掉EJB的命，并且推出了一个影响后世深远的利器——Spring框架。Spring抛弃了EJB，而是提供一个spring容器，通过依赖注入的技术来管理POJO们，而项目用到的事务和安全等通过AOP技术在运行时动态织入POJO中。这种方式既解决了EJB太重，还保留了程序员对事务、安全的需求，Spring迅速在Java程序员中流行起来。虽然EJB后来也模仿Spring，简化了开发和配置，然而Java程序员们对原创者给予了充分的信任和尊重，Spring已然成为了新的事实上的标准。不过，令人欣慰的是，Spring中的POJO依然被叫做bean。

Java bean这个小豆子在客户端争端战中诞生，虽临危受命并被寄予了厚望，然而终未能成功。可小豆子却在Java后端开发中享受雨露滋润，逐渐生长为Jsp Model1，Jsp Model2，也可谓顺风顺水，终于成长为了参天大树EJB。生生死死、周而复始是生命的特征，似乎也是开源的特征。EJB最终落入了尘土，但顽强的Java bean却没有死亡，在新的春天(Spring)中它又发芽生根，迎来重生。未来依然充满了很多不确定性，小豆子面临的机遇和挑战并存，我们无法预知Java bean终究会发展成什么样子，但是生生死死都是生命，生命都值得敬畏。

下期为您带来管理篇内容：沟通力就是领导力！

欢迎大家关注分享ToCTO，每周为您带来最硬核的技术分享和最有效的管理方法！