上一篇提到Java bean 的规范虽然定义的不错， 但却没有获得意料中的成功， 尤其是Java帝国所期待的桌面开发组件化市场上。
我和小码哥多么期待优快云也能出一期《程序员大本营》， 里边包含成千上万的java bean 组件啊。
不要幻想了， 赶紧把java bean 应用在服务器端才是正事。
JSP + Java Bean
小码哥建议先用在jsp上试试， 可以用java bean 来封装业务逻辑，保存数据到数据库， 像这样：
（微信公众号"码农翻身"注： 这其实叫做JSP Model 1 )
其中jsp 直接用来接受用户的请求， 然后通过java bean 来处理业务， 具体的使用方法是：
<jsp:useBean id="user" scope="page" class="com.coderising.User"/>
<jsp:setProperty property="userName" name="user" param="userName"/>
<jsp:setProperty property="password" name="user" param="password"/>
这就能把HTTP request中的所有参数都设置到 user 这个java bean 对应的属性上去。
如果想偷懒， 还可以这样：
<jsp:setProperty name="user" property="*"/>
当然要保证 http request中的参数名和 java bean 中的属性名是一样的。
这个叫做JSP Model 1 的模型受到了很多Java程序员的欢迎 , 因为他们的应用规模都很小， 用Model 1 使得开发很快速。
实际上， 这种方式和微软帝国的asp , 以及和开源的php 几乎一样。
但很快就有人来找我抱怨了， 说他们的项目中使用了Model 1 导致整个系统的崩溃。
他说： “你知道吗？ 我们的系统中有好几千个jsp， 这些jsp互相调用(通过GET/POST), 到了最后调用关系无人能搞懂。 ”
其实我们已经预料到了， 小码哥对此有个形象的比喻：意大利面条
这几千个JSP 就像这碗面条一样，搅在一起， 根本理不清楚。
为了解决这个问题，小码哥又推出了 ：JSP Model 2 , 这是个模型真正的体现了Model-View-Controller的思想：
Servlet 充当Controller , jsp 充当 View
Java bean 当然就是Model 了！
业务逻辑， 页面显示， 和处理过程做了很好的分离。
基于这个模型的扩展和改进， 很多Web开发框架开始如雨后春笋一样出现， 其中最著名的就是Struts， SpringMVC 了。
Java Web开发迅速的繁荣了。
我们再一次体会到了开放的好处 ！
Enterprise Java bean
但是好景不长， 自从Java帝国统治了所谓的“企业级应用”开发领地， 各种各样的游行和抗议层出不穷：
“我们要分布式”
“我们要安全”
“我们要事务”
“我们要高可用性”
“......”
帝国分析了一下， 其实这些程序员的诉求可以归结为：
“我们只想关注我们的业务逻辑， 我们不想， 也不应该由我们来处理‘低级’的事务， 多线程，连接池，以及其他各种各种的‘低级’API， 此外Java帝国一定得提供集群功能， 这样我们的一台机器死机以后，整个系统还能运转。 ”
我们不能坐着不管， 企业级应用是我们的命根子。
小码哥彻夜工作， 最终拿出了一个叫做J2EE的东西， 像Java bean 一样， 这还是一个规范， 但是比Java bean 复杂的多， 其中有：
JDBC: Java 数据库连接， 没有数据库的支持怎么能叫企业级应用？
JNDI : Java 命名和目录接口， 通过一个名称就可以定位到一个数据源， 连jdbc连接都不用了
RMI： 远程过程调用， 让一个机器上的java 对象可以调用另外一个机器上的java 对象 ， 你们不是要分布式吗？
JMS : Java 消息服务， 可以使用消息队列了， 这不是企业级应用非常需要的吗？
JTA： Java 事务管理， 支持分布式事务， 能在访问、更新多个数据库的时候，仍然保证事务， 还是分布式。
Java mail : 收发邮件也是必不可少的啊。
刘欣（微信公众号号：码农翻身）注： J2EE 后来改成了Java EE。
当然还有最最最重要的升级， 小码哥把java bean 变成了 Enterprise Java bean , 简称 EJB。
小码哥宣称：
使用了EJB， 你就可以把精力只放在业务上了， 那些烦人的事务管理， 安全管理，线程 统统交给容器（应用服务器）来处理吧。
我们还提供了额外的福利， 只要你的应用服务器是由多个机器组成的集群， EJB就可以无缝的运行在这个集群上， 你完全不用考虑一个机器死掉了应用该怎么办。我们都帮你搞定了。
使用Session Bean ， 可以轻松的处理你的业务。
使用实体Bean (Entity bean ) , 你和数据库打交道会变得极为轻松， 甚至sql 都不用写了。
使用消息驱动Bean(Message Driven bean ) , 你可以轻松的和一个消息队列连接， 处理消息。
听起来很美好是不是？
企业级开发领地的程序员们欢呼雀跃， 坐上了J2EE这条船，似乎一下子高贵起来， 开始鄙视微软的ASP, 开源的PHP, Python 等“不入流”的语言了 。
Weblogic , Websphere等符合J2EE规范的应用服务器趁势而上， 摇旗呐喊， 仿佛一个新的时代要来临了， 当然他们在背后一直闷声发大财。
Sring
有句古话是对的， 捧的越高， 跌的越惨。
很快，大部分的程序员就发现， 美好的前景并没有实现， EJB中用起来极为繁琐和笨重， 性能也不好， 为了获得所谓的分布式，反而背上了沉重的枷锁。
实体Bean很快没人用了， 就连简单的无状态Session bean 也被大家所诟病， 其中一条罪状就是“代码的侵入性”。
也是， 小码哥定义EJB的时候没考虑那么多，程序员在定义一个Session bean的时候，需要写一大堆和业务完全没有关系的类。
还需要被迫实现一些根本不应该实现的接口及其方法：
为了哪怕一点点业务逻辑， 我们都得写这么多无用的代码 ！ 程序员们出离愤怒了！
他们发起了一场叫做POJO (Plain Old Java Object)的运动， 高唱这POJO之歌， 要求我们整改。
他们希望这个样子：
public class HelloworldBean{
public String hello(){
return "hello world"
}
}
与此同时，他们还过分的要求保留事务了， 安全了这些必备的东西。
程序员确实不好伺候， 但是我们已经被Weblogic, Websphere这些大佬们“绑架”， 想改动谈何容易 ！
2002年， 小码哥看到了Rod Johnson写的一本书《Expert one on one J2EE development withoutEJB》 ， 赶紧跑来找我：
“老大， 坏了坏了， 你快看看这本书吧， 这个叫Rod的家伙写的这本书直击我们的命门，这厮要搞without EJB”
（微信公众号"码农翻身"注： 虽然这本书翻译的很差，但由于是spring的开山之作，还是值得读一下， 最好中英文对照)
岂止是without EJB, 他还“偷偷的”推出了一个叫什么Spring的框架， 已经迅速的流行开了。
Spring 框架顺应了POJO的潮流， 提供了一个spring 的容器来管理这些POJO, 好玩的是也叫做bean 。
看来我们的java bean 走了一圈又回到了原点。
对于一个Bean 来说，如果你依赖别的Bean , 只需要声明即可， spring 容器负责把依赖的bean 给“注入进去“， 起初大家称之为控制反转(IoC)
后来 Martin flower 给这种方式起来个更好的名字，叫“依赖注入”。
如果一个Bean 需要一些像事务，日志，安全这样的通用的服务， 也是只需要声明即可， spring 容器在运行时能够动态的“织入”这些服务， 这叫AOP。
后来我和小码哥商量， 我们EJB也学习Spring , 简化开发和配置， 但是为时已晚， Spring 已经成为事实上的标准了！程序员已经被spring 拉走了！
不过令我们欣慰的是， spring和spring mvc极大的增加了我们对web开发领地的统治力, java 帝国更加强盛了。
（全文完）
声明：原创文章，未经授权， 禁止转载。
热门文章：
公共号：码农翻身
“码农翻身”公众号由工作15年的前IBM架构师创建，分享编程和职场的经验教训。
615
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
