举个例子，假如有人要用Java实现一个单向链表类，可能会这样写：
上述实现为了能够快速获取链表的大小，把链表大小缓存在size变量中。用法如下：
JavaIntList myList = new JavaIntList( );
System.out.println(myList.size);
要节省内存，不要缓存size变量了，把代码改成这样：
创造找不到什么size变量。如果要找到size变量，你就必须保持向后兼容性。以是Java标准库中，绝对不会涌现public int size这样的代码，而一定会一开始就写成：
private int size;
public int getSize( ){return size;}
让用户一开始就利用getSize，以便有朝一日修正getSize实现时，不毁坏向后兼容性。这种public int getSize() { return size; }的惯用手腕，便是Java Bean。
JSP + Java Bean在jsp上， 可以用java bean 来封装业务逻辑，保存数据到数据库， 像这样：
个中jsp 直接用来接管用户的要求， 然后通过java bean 来处理业务， 详细的利用方法是：
这就能把HTTP request中的所有参数都设置到 user 这个java bean 对应的属性上去。
只要担保 http request中的参数名和 java bean 中的属性名是一样的。
这个叫做JSP Model 1 的模型受到了很多Java程序员的欢迎 , 由于他们的运用规模都很小， 用Model 1 使得开拓很快速，实际上， 这种办法和微软的asp , 以及和开源的php 险些一样。
但在项目中频繁利用了Model 1 导致全体系统的崩溃，由于系统中有好几千个jsp， 这些jsp相互调用(通过GET/POST), 到了末了调用关系无人能搞懂。
为理解决这个问题，又推出了 ：JSP Model 2 , 这是个模型真正的表示了Model-View-Controller的思想：
Servlet 充当Controller , jsp 充当 View ，Java bean 当然便是Model 了！
业务逻辑， 页面显示， 和处理过程做了很好的分离。
基于这个模型的扩展和改进， 很多Web开拓框架开始如雨后春笋一样涌现， 个中最著名的便是 SpringMVC了。
Enterprise Java bean越来越多企业程序员提出诉求：要分布式、要安全、要事务、要高可用性。
诉求可以归结为：“我们只想关注我们的业务逻辑， 我们不想， 也不应该由我们来处理‘低级’的事务， 多线程，连接池，以及其他各种各种的‘低级’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 ) , 你可以轻松的和一个行列步队连接， 处理。
Spring然而，大部分的程序员就创造， EJB中用起来极为繁琐和笨重， 性能也不好， 为了得到所谓的分布式，反而背上了沉重的枷锁。
实体Bean很快没人用了， 就连大略的无状态Session bean 也被大家所诟病， 个中一条罪状便是“代码的侵入性”。
在定义EJB的时候没考虑那么多，程序员在定义一个Session bean的时候，须要写一大堆和业务完备没有关系的类。
还须要被迫实现一些根本不应该实现的接口及其方法：
他们希望这个样子：
public class HelloworldBean{
public String hello(){
return "hello world"
}
}
与此同时，他们还过分的哀求保留事务、 安全这些必备的东西。
Spring 框架顺应了POJO的潮流， 供应了一个spring 的容器来管理这些POJO, 也叫bean 。
对付一个Bean 来说，如果你依赖别的Bean , 只须要声明即可， spring 容器卖力把依赖的bean 给“注入进去“， 起初大家称之为掌握反转(IoC)。
后来 Martin flower 给这种办法起来个更好的名字，叫“依赖注入”（DI）。
如果一个Bean 须要一些像事务，日志，安全这样的通用的做事， 也是只须要声明即可， spring 容器在运行时能够动态的“织入”这些做事， 这叫面向切面（AOP）。
总之，spring和spring mvc极大的增加了Java对web开拓领地的统治力。
JavaBean 和 Spring中Bean的差异先理解一下各自是什么吧!
Jave beanjavaBean大略的讲便是实体类，用来封装工具，这个类里面全部都是属性值，和get，set方法。大略笼统的说便是一个类，一个可复用的类。javaBean在MVC设计模型中是model，又称模型层，在一样平常的程序中，我们称它为数据层，便是用来设置数据的属性和一些行为，然后我会供应获取属性和设置属性的get/set方法JavaBean是一种JAVA措辞写成的可重用组件。为写成JavaBean，类必须是详细的和公共的，并且具有无参数的布局器。
spring bean对付利用Spring框架的开拓职员来说，我们紧张做的紧张有两件事情：①开拓Bean;②配置Bean;而Spring帮我们做的便是根据配置文件来创建Bean实例，并调用Bean实例的方法来完成“依赖注入”，可以把Spring容器理解成一个大型工厂，Bean便是该工厂的产品，工厂(Spirng容器)里能生产出来什么样的产品（Bean），完备取决于我们在配置文件中的配置。实在便是根据配置文件产生工具,而不须要人为的手动去创造工具,降落了耦合.
用途不同：传统javabean更多地作为值通报参数，而spring中的bean用途险些无处不在，任何组件都可以被称为bean。
写法不同：传统javabean作为值工具，哀求每个属性都供应getter和setter方法；但spring中的bean只需为接管设值注入的属性供应setter方法。
javabean的写法:
public class A{private String a;private void setA(String a){this.a = a;}private String getA(){return a;}}springbean的写法<bean id="p1" class="com.zking.Pojo.Person" scope="prototype">//及时加载 加载你的xml配置文件ApplicationContext applicationContext = new ClassPathXmlApplicationContext("ApplicationContext.xml");//getbean输入你配置类的别名得到 person工具 Person p = (Person) applicationContext.getBean("p1");
id是给这个工具定的别名 class是这个实体类的全路径名 根据配置文件来创建Bean实例，并调用Bean实例的方法 bean里面还有很多属性
生命周期不同：传统javabean作为值工具通报，不接管任何容器管理其生命周期；spring中的bean有spring管理其生命周期行为。
所有可以被spring容器实例化并管理的java类都可以称为bean。
原来做事器处理页面返回的值都是直策应用request工具，后来增加了javabean来管理工具，所有页面值只假如和javabean对应，就可以用类.GET属性方法来获取值。javabean不但可以传参数，也可以处理数据，相称与把一个做事器实行的类放到了页面上，使工具管理相对不那么乱（比拟asp的时候所有内容都在页面上完成）。
spring中的bean，是通过配置文件、javaconfig等的设置，有spring自动实例化，用完后自动销毁的工具。让我们只须要在用的时候利用工具就可以，不用考虑如果创建类工具（这便是spring的注入）。一样平常是用在做事器端代码的实行上。
参考文章https://blog.csdn.net/hmh13548571896/article/details/100628104
https://www.cnblogs.com/xll1025/p/11366413.html
https://blog.csdn.net/qqqnzhky/article/details/82747333
https://www.cnblogs.com/mike-mei/p/9712836.html
https://blog.csdn.net/qq_42245219/article/details/82748460
