Servlet jsp
类装载及实例创建阶段、实例初始化阶段、服务阶段以及实例销毁阶段。
1、运行速度上比CGI快,因为使用了多线程
2、servlet使用了标准的api,可被许多web服务支持
3、与系统无关性,一次编译多次使用
1,初始化阶段 调用init()方法
2,响应客户请求阶段 调用service()方法
3,终止阶段 调用destroy()方法
Servlet初始化阶段:
在下列时刻Servlet容器装载Servlet:
1,Servlet容器启动时自动装载某些Servlet,实现它只需要在web.XML文件中的<Servlet></Servlet>之间添加如下代码:
<loadon-startup>1</loadon-startup> |
2,在Servlet容器启动后,客户首次向Servlet发送请求
3,Servlet类文件被更新后,重新装载Servlet
servlet简单说是服务端运行的脚本。
优点是响应客户端的请求,根据请求动态响应,最大的优点不是生成网页,而是做为一个服务(比如windows里得服务那样。),控制程序的流向,过滤等。
mvc中,控制就是servlet。比喻就是一个指挥官得角色。
而生存网页就用jsp来,jsp本身就是一个servlet。而且里面可以用html语言
Struts1
1. 初始化: struts框架的总控制器ActionServlet是一个Servlet,它在web.xml中配置成自动 启动的Servlet,在启动时总控制器会读取配置文件(struts-config.xml)的配置信息,为struts
中不同的模块初始化相应的对象。(面向对象思想)
2. 发送请求:用户提交表单或通过URL向WEB服务器提交请求,请求的数据用HTTP协议传给web服务器。
3. form填充:struts的总控制器ActionServlet在用户提交请求时将数据放到对应的form对象中的成员变量中。
4. 派发请求:控制器根据配置信息对象ActionConfig将请求派发到具体的Action,对应的formBean一并传给这个Action中的excute()方法。
5.处理业务:Action一般只包含一个excute()方法,它负责执行相应的业务逻辑(调用其它的业务模块)完毕后返回一个ActionForward对象。服务器通过ActionForward对象进行转发工作。
6.返回响应:Action将业务处理的不同结果返回一个目标响应对象给总控制器。
7.查找响应:总控制器根据Action处理业务返回的目标响应对象,找到对应的资源对象,一般情况下为jsp页面。
8.响应用户:目标响应对象将结果传递给资源对象,将结果展现给用户。
Struts2
Struts2框架由3个部分组成:核心控制器FilterDispatcher、业务控制器和用户实现的业务逻辑组件。在这3个部分里,Struts 2框架提供了核心控制器FilterDispatcher,而用户需要实现业务控制器和业务逻辑组件。
(1)核心控制器:FilterDispatcher
FilterDispatcher是Struts2框架的核心控制器,该控制器作为一个Filter运行在Web应用中,它负责拦截所有的用户请求,当用户请求到达时,该Filter会过滤用户请求。如果用户请求以action结尾,该请求将被转入Struts2框架处理。
Struts2框架获得了*.action请求后,将根据*.action请求的前面部分决定调用哪个业务逻辑组件,例如,对于login.action请求,Struts2调用名为login的Action来处理该请求。
Struts2应用中的Action都被定义在struts.xml文件中,在该文件中定义Action时,定义了该Action的name属性和class属性,其中name属性决定了该Action处理哪个用户请求,而class属性决定了该Action的实现类。
Struts2用于处理用户请求的Action实例,并不是用户实现的业务控制器,而是Action代理——因为用户实现的业务控制器并没有与Servlet API耦合,显然无法处理用户请求。而Struts2框架提供了系列拦截器,该系列拦截器负责将HttpServletRequest请求中的请求参数解析出来,传入到Action中,并回调Action 的execute方法来处理用户请求。
(2)一个请求在Struts2框架中的处理大概分为以下几个步骤
1 .客户端初始化一个指向Servlet容器(例如Tomcat)的请求 ,即HttpServletRequest请求。
2 .这个请求经过一系列的过滤器(Filter)(这些过滤器中有一个叫做ActionContextCleanUp的可选过滤器,这个过滤器对于Struts2和其他框架的集成很有帮助,例如:SiteMesh Plugin)
3. 接着FilterDispatcher被调用,FilterDispatcher询问ActionMapper来决定这个请是否需要调用某个Action
4 .如果ActionMapper决定需要调用某个Action,FilterDispatcher把请求的处理交给ActionProxy
5 .ActionProxy通过Configuration Manager询问框架的配置文件,找到需要调用的Action类
6 .ActionProxy创建一个ActionInvocation的实例。
7 .ActionInvocation实例使用命名模式来调用,在调用Action的过程前后,涉及到相关拦截器(Intercepter)的调用。
8 .一旦Action执行完毕,ActionInvocation负责根据struts.xml中的配置找到对应的返回结果。返回结果通常是(但不总是,也可 能是另外的一个Action链)一个需要被表示的JSP或者FreeMarker的模版。在表示的过程中可以使用Struts2 框架中继承的标签。在这个过程中需要涉及到ActionMapper
在上述过程中所有的对象(Action,Results,Interceptors,等)都是通过ObjectFactory来创建的。
Action 类:
Struts1要求Action类继承一个抽象基类。Struts1的一个普遍问题是使用抽象类编程而不是接口。
Struts 2 Action类可以实现一个Action接口,也可实现其他接口,使可选和定制的服务成为可能。Struts2提供一个ActionSupport基类去实现 常用的接口。Action接口不是必须的,任何有execute标识的POJO对象都可以用作Struts2的Action对象。
线程模式:
Struts1 Action是单例模式并且必须是线程安全的,因为仅有Action的一个实例来处理所有的请求。单例策略限制了Struts1 Action能作的事,并且要在开发时特别小心。Action资源必须是线程安全的或同步的。
Struts2 Action对象为每一个请求产生一个实例,因此没有线程安全问题。(实际上,servlet容器给每个请求产生许多可丢弃的对象,并且不会导致性能和垃圾回收问题)
Servlet 依赖:
Struts1 Action 依赖于Servlet API ,因为当一个Action被调用时HttpServletRequest 和 HttpServletResponse 被传递给execute方法。
Struts 2 Action不依赖于容器,允许Action脱离容器单独被测试。如果需要,Struts2 Action仍然可以访问初始的request和response。但是,其他的元素减少或者消除了直接访问HttpServetRequest 和 HttpServletResponse的必要性。
可测性:
测试Struts1 Action的一个主要问题是execute方法暴露了servlet API(这使得测试要依赖于容器)。一个第三方扩展--Struts TestCase--提供了一套Struts1的模拟对象(来进行测试)。
Struts 2 Action可以通过初始化、设置属性、调用方法来测试,“依赖注入”支持也使测试更容易。
捕获输入:
Struts1 使用ActionForm对象捕获输入。所有的ActionForm必须继承一个基类。因为其他JavaBean不能用作ActionForm,开发者经常创建多余的类捕获输入。动态Bean(DynaBeans)可以作为创建传统ActionForm的选择,但是,开发者可能是在重新描述(创建)已经存在的JavaBean(仍然会导致有冗余的javabean)。
Struts 2直接使用Action属性作为输入属性,消除了对第二个输入对象的需求。输入属性可能是有自己(子)属性的rich对象类型。Action属性能够通过web页面上的taglibs访问。Struts2也支持ActionForm模式。rich对象类型,包括业务对象,能够用作输入/输出对象。这种ModelDriven 特性简化了taglib对POJO输入对象的引用。
表达式语言:
Struts1 整合了JSTL,因此使用JSTL EL。这种EL有基本对象图遍历,但是对集合和索引属性的支持很弱。
Struts2可以使用JSTL,但是也支持一个更强大和灵活的表达式语言--"Object Graph Notation Language" (OGNL).
绑定值到页面(view):
Struts 1使用标准JSP机制把对象绑定到页面中来访问。
Struts 2 使用 "ValueStack"技术,使taglib能够访问值而不需要把你的页面(view)和对象绑定起来。ValueStack策略允许通过一系列名称相同但类型不同的属性重用页面(view)。
类型转换:
Struts 1 ActionForm 属性通常都是String类型。Struts1使用Commons-Beanutils进行类型转换。每个类一个转换器,对每一个实例来说是不可配置的。
Struts2 使用OGNL进行类型转换。提供基本和常用对象的转换器。
校验:
Struts 1支持在ActionForm的validate方法中手动校验,或者通过Commons Validator的扩展来校验。同一个类可以有不同的校验内容,但不能校验子对象。
Struts2支持通过validate方法和XWork校验框架来进行校验。XWork校验框架使用为属性类类型定义的校验和内容校验,来支持chain校验子属性
Action执行的控制:
Struts1支持每一个模块有单独的Request Processors(生命周期),但是模块中的所有Action必须共享相同的生命周期。
Struts2支持通过拦截器堆栈(Interceptor Stacks)为每一个Action创建不同的生命周期。堆栈能够根据需要和不同的Action一起使用。
Struts作为MVC 2的Web框架,自推出以来不断受到开发者的追捧,得到用广泛的应用。作为最成功的Web框架,Struts自然拥有众多的优点:
springMVC
1)DispatcherServlet接收到请求后,根据对应配置文件中配置的处理器映射,找到对应的处理器映射项(HandlerMapping),根据配置的映射规则,找到对应的处理器(Handler)。
2)调用相应处理器中的处理方法,处理该请求,处理器处理结束后会将一个ModelAndView类型的数据传给DispatcherServlet,这其中包含了处理结果的视图和视图中要使用的数据。
3)DispatcherServlet根据得到的ModelAndView中的视图对象,找到一个合适的ViewResolver(视图解析器),根据视图解析器的配置,DispatcherServlet将视图要显示的数据传给对应的视图,最后给浏览器构造一个HTTP响应。
DispatcherServlet是整个Spring MVC的核心。它负责接收HTTP请求组织协调Spring MVC的各个组成部分。其主要工作有以下三项:
1)截获符合特定格式的URL请求。
2)初始化DispatcherServlet上下文对应的WebApplicationContext,并将其与业务层、持久化层的WebApplicationContext建立关联。
3)初始化Spring MVC的各个组成组件,并装配到DispatcherServlet中。
1。Spring MVC的controller+command object模式比Struts2的Action模式更安全一些。而在Struts2中,自动数据绑定发生在Action对象上。这样,在Action类中任何有Set方法的属性都有可能被http request的参数覆盖,在设计Action类时如果不小心,就可能会产生安全隐患。比如某个身份认证方案可能会依赖于Action的某个属性,如role来判断用户是否具有访问该action的权限。这样,恶意用户可以通过在request参数中包含一个role参数来改写action本身对role属性的设置。
在Spring MVC中,controller和command object是两个独立的类,自动数据绑定只发生在command object上,对controller没有影响,就不存在这个问题。
2。Struts 2的action类本身是线程不安全的,不能使用singleton模式来创建。在我看来,这个是比较ugly的。特别是一些处理逻辑比较复杂的action,每次创建一个新对象实例的代价可能是比较高的。而Spring MVC的command object基本上都是POJO,创建实例的代价很低。
3。Struts 2的jsp tags使用OGNL作为表达式语言。我个人觉得这个语言功能过强,特别是能够直接访问action本身的方法,这类功能很容易被滥用,从而重蹈过去jsp<% %>标记的覆辙。
当然,Struts 2也有很多功能是值得Spring吸取的,比如redirect-action,对namespace的支持等等。特别是Struts 2的底层框架XWork的最新版本2.0beta3已经支持基于annotation的validation,这个Spring应该尽快跟进。
不过我还是觉得Spring MVC更好些。
ORM
JDBC
<1>. 结构:
DriverManager (是一工厂实现类,用了工厂方法模式)
|
Dirver (是驱动程序对象的接口,指向具体数据库驱动程序对象=DriverManager.getDriver(String URL))
|
Connection (是连接对象接口,指向具体数据库连接对象=Drivermanager.getConnection(String URL))
|
Statement (执行静态SQL语句接口,=Connection.CreateStatement())
|
ResultSet (是指向结果集对象的接口,=Statement.excuteXXX())
<2>.工作原理:
1.装载驱动程序:(实例化时自动向DriverManager注册(DriverManager.registerDriver())
<1>.Class.forName(driver)
<2>.Class.forName(driver).newInstance()
<3>.new driver()
2.取得数据库连接(Connect to the DataBase)
<1>.用DriverManager取数据库连接
Connection cn = DriverManager.getConnection(url,uid,pwd);
<2>.用jndi(java的命名和目录服务)方式:多用于jsp
Context ctx = (Context) new InitialContext().lookup("java:comp/env");
DataSource ds = (DataSource) ctx.lookup(jndi);
Connection cn = ds.getConnection();
3.执行sql语句(Execute the SQL)
<1>.用Statement来执行sql语句(主要是不带参的SQL)
Statement sm = cn.createStatement();
sm.executeQuery(sql); // 执行数据查询语句(select)
sm.executeUpdate(sql); // 执行数据更新语句(delete、update、insert、drop等)
<2>.用PreparedStatement来执行sql语句(带参SQL)
String sql = "insert into CUSTOMER(id,name) values (?,?)";
PreparedStatement ps = cn.prepareStatement(sql);
ps.setInt(1,xxx);
ps.setString(2,xxx);
...
ResultSet rs = ps.executeQuery(); // 查询
int c = ps.executeUpdate(); // 更新
<3>.用PreparedStatement来执行sql语句(批量更新或删除SQL)
PreparedStatement pstmt = con.prepareStatement("UPDATE EMPLOYEES SET SALARY = ? WHERE ID = ?");
for(int i =0;i<length;i++){
pstmt.setBigDecimal(1, param1[i]);
pstmt.setInt(2, param2[i]);
pstmt.addBatch();
}
pstmt. executeBatch();
<4>.用CallablePrepareStatement来调用存储过程
CallableStatement cstmt = con.prepareCall("{call getTestData(?, ?)}");
cstmt.registerOutParameter(1, java.sql.Types.TINYINT);
cstmt.registerOutParameter(2, java.sql.Types.DECIMAL, 3);
cstmt.executeQuery();
byte x = cstmt.getByte(1);
java.math.BigDecimal n = cstmt.getBigDecimal(2, 3);
4.事务的处理(JDBC的事务处理简单,在执行多条更新语句后,加cn.commit()或cn.rollback()就可以)
<1>.关闭Connection的自动提交
connection.setAutoCommit(false);
<2>.执行一系列sql语句:执行新sql前,以前的Statement(或PreparedStatemet)须close
Statement sm ;
sm = cn.createStatement(insert into user...);
sm.executeUpdate();
sm.close();
sm = cn.createStatement("insert into corp...);
sm.executeUpdate();
sm.close();
<3>.提交
cn.commit();
<4>.如果发生异常,回滚:
cn.rollback();
5.处理执行结果:
<1>.查询语句,返回记录集ResultSet
<2>.更新语句,返回数字,表示该更新影响的记录数(0,表示未更新,-1表示更新失败)
<3>.ResultSet的方法:while(re.next())
next(),将游标往后移动一行,如果成功返回true;否则返回false
getInt("id")或getSting("name"),返回当前游标下某个字段的值
6.关闭数据库连接
rs.close();
ps.close(); /stat.close();
con.close();
Hibernate
1. 对JDBC访问数据库的代码做了封装,大大简化了数据访问层繁琐的重复性代码。
2. Hibernate是一个基于JDBC的主流持久化框架,是一个优秀的ORM实现。他很大程度的简化DAO层的编码工作
3. hibernate使用Java反射机制,而不是字节码增强程序来实现透明性。
4. hibernate的性能非常好,因为它是个轻量级框架。映射的灵活性很出色。它支持各种关系数据库,从一对一到多对多的各种复杂关系
原理:
1.通过Configuration().configure();读取并解析hibernate.cfg.xml配置文件
2.由hibernate.cfg.xml中的<mapping resource="com/xx/User.hbm.xml"/>读取并解析映射信息
3.通过config.buildSessionFactory();//创建SessionFactory
4.sessionFactory.openSession();//打开Sesssion
5.session.beginTransaction();//创建事务Transation
6.persistent operate持久化操作
7.session.getTransaction().commit();//提交事务
8.关闭Session
9.关闭SesstionFactory
Hibernate可以应用在任何使用JDBC的场合,既可以在Java的客户端程序实用,也可以在Servlet/JSP的Web应用中使用,最具革命意义的是,Hibernate可以在应用EJB的J2EE架构中取代CMP,完成数据持久化的重任。
优点:
a. Hibernate 使用 Java 反射机制 而不是字节码增强程序来实现透明性。
b.Hibernate 的性能非常好,因为它是个轻量级框架。 映射的灵活性很出色。
c. 它支持各种关系数据库,从一对一到多对多的各种复杂关系。
缺点:
它限制您所使用的对象模型。(例如,一个持久性类不能映射到多个表)其独有的界面和可怜的市场份额也让人不安
◆两者都是JAVA的数据库操作中间件。
◆两者对于数据库进行直接操作的对象都不是线程安全的,都需要及时关闭。
◆两者都可以对数据库的更新操作进行显式的事务处理。
不同点:
◆使用的SQL语言不同:JDBC使用的是基于关系型数据库的标准SQL语言,Hibernate使用的是HQL(Hibernate query language)语言
◆操作的对象不同:JDBC操作的是数据,将数据通过SQL语句直接传送到数据库中执行,Hibernate操作的是持久化对象,由底层持久化对象的数据更新到数据库中。
◆数据状态不同:JDBC操作的数据是“瞬时”的,变量的值无法与数据库中的值保持一致,而Hibernate操作的数据是可持久的,即持久化对象的数据属性的值是可以跟数据库中的值保持一致的。
优点:
hibernate的最主要的几个优点是:
一、hibernate可以让开发人员以面相对象的思想来操作数据库。jdbc只能通过SQL语句将元数据传送给数据库,进行数据操作。而hibernate可以在底层对元数据和对象进行转化,使得开发者只用面向对象的方式来存取数据即可。
二、hibernate使用xml或JPA的配置以及数据库方言等等的机制,使得hibernate具有更好的移植性,对于不同的数据库,开发者只需要使用相同的数据操作即可,无需关心数据库之间的差异。而直接使用JDBC就不得不考虑数据库差异的问题。
三、hibernate提供了大量的封装(这也是它最大的缺点),很多数据操作以及关联关系等都被封装的很好,开发者不需写大量的sql语句,这就极大的提高了开发者的开发效率。
四、hibernate提供了缓存机制(session缓存,二级缓存,查询缓存),对于那些改动不大且经常使用的数据,可以将它们放到缓存中,不必在每次使用时都去查询数据库,缓存机制对提升性能大有裨益。
Mybatis
半自动化
mybatis是把sql语句与java代码分离了...sql语句在xml文件配置的...
iBATIS 是另外一种优秀的O/R mapping框架,当前版本是2.0。目前属于apache的一个子项目了。
相对Hibernate“O/R”而言,iBATIS 是一种“Sql Mapping”的ORM实现。
Hibernate对数据库结构提供了较为完整的封装,Hibernate的O/R Mapping实现了POJO 和数据库表之间的映射,以及SQL 的自动生成和执行。程序员往往只需定义好了POJO 到数据库表的映射关系,即可通过Hibernate 提供的方法完成持久层操作。程序员甚至不需要对SQL 的熟练掌握, Hibernate/OJB 会根据制定的存储逻辑,自动生成对应的SQL 并调用JDBC 接口加以执行。
而iBATIS 的着力点,则在于POJO 与SQL之间的映射关系。也就是说,iBATIS并不会为程序员在运行期自动生成SQL 执行。具体的SQL 需要程序员编写,然后通过映射配置文件,将SQL所需的参数,以及返回的结果字段映射到指定POJO。
使用iBATIS 提供的ORM机制,对业务逻辑实现人员而言,面对的是纯粹的Java对象,
这一层与通过Hibernate 实现ORM 而言基本一致,而对于具体的数据操作,Hibernate会自动生成SQL 语句,而iBATIS 则要求开发者编写具体的SQL 语句。相对Hibernate而言,iBATIS 以SQL开发的工作量和数据库移植性上的让步,为系统设计提供了更大的自由空间。
二者的对比:
1. iBATIS非常简单易学,Hibernate相对较复杂,门槛较高。
2. 二者都是比较优秀的开源产品
3. 当系统属于二次开发,无法对数据库结构做到控制和修改,那iBATIS的灵活性将比Hibernate更适合
4. 系统数据处理量巨大,性能要求极为苛刻,这往往意味着我们必须通过经过高度优化的SQL语句(或存储过程)才能达到系统性能设计指标。在这种情况下iBATIS会有更好的可控性和表现。
5. iBATIS需要手写sql语句,也可以生成一部分,Hibernate则基本上可以自动生成,偶尔会写一些Hql。同样的需求,iBATIS的工作量比 Hibernate要大很多。类似的,如果涉及到数据库字段的修改,Hibernate修改的地方很少,而iBATIS要把那些sql mapping的地方一一修改。
6. 以数据库字段一一对应映射得到的PO和Hibernte这种对象化映射得到的PO是截然不同的,本质区别在于这种PO是扁平化的,不像Hibernate映射的PO是可以表达立体的对象继承,聚合等等关系的,这将会直接影响到你的整个软件系统的设计思路。
7. Hibernate现在已经是主流O/R Mapping框架,从文档的丰富性,产品的完善性,版本的开发速度都要强于iBATIS
springdataJpa
Spring Data JPA帮助我们自动完成了持久层的业务逻辑处理,我们要做的,仅仅是声明一个持久层接口。
可以使用的仓库接口有:
Repository: 是 Spring Data的一个核心接口,它不提供任何方法,开发者需要在自己定义的接口中声明需要的方法。
CrudRepository: 继承Repository,提供增删改查方法,可以直接调用。
PagingAndSortingRepository: 继承CrudRepository,具有分页查询和排序功能
JpaRepository: 继承PagingAndSortingRepository,针对JPA技术提供的接口
JpaSpecificationExecutor: 可以执行原生SQL查询
Spring
一、 IoC(Inversion of control): 控制反转
1、IoC:
概念:控制权由对象本身转向容器;由容器根据配置文件去创建实例并创建各个实例之间的依赖关系
核心:bean工厂;在Spring中,bean工厂创建的各个实例称作bean
二、AOP(Aspect-Oriented Programming): 面向方面编程
1、 代理的两种方式:
静态代理:
l 针对每个具体类分别编写代理类;
l 针对一个接口编写一个代理类;
动态代理:
针对一个方面编写一个InvocationHandler,然后借用JDK反射包中的Proxy类为各种接口动态生成相应的代理类
2、 AOP的主要原理:动态代理
Spring 已经用过一段时间了,感觉Spring是个很不错的框架。内部最核心的就是IOC了,
动态注入,让一个对象的创建不用new了,可以自动的生产,这其实就是利用java里的反射
反射其实就是在运行时动态的去创建、调用对象,Spring就是在运行时,跟xml Spring的配置
文件来动态的创建对象,和调用对象里的方法的 。
Spring还有一个核心就是AOP这个就是面向切面编程,可以为某一类对象 进行监督和控制(也就是
在调用这类对象的具体方法的前后去调用你指定的 模块)从而达到对一个模块扩充的功能。这些都是通过
配置类达到的。
Spring目的:就是让对象与对象(模块与模块)之间的关系没有通过代码来关联,都是通过配置类说明
管理的(Spring根据这些配置 内部通过反射去动态的组装对象)
要记住:Spring是一个容器,凡是在容器里的对象才会有Spring所提供的这些服务和功能。
Spring里用的最经典的一个设计模式就是:模板方法模式。(这里我都不介绍了,是一个很常用的设计模式)
Spring里的配置是很多的,很难都记住,但是Spring里的精华也无非就是以上的两点,把以上两点跟理解了
也就基本上掌握了Spring.
Tomcat
Tomcat 很受广大程序员的喜欢,因为它运行时占用的系统资源小,扩展性好,支持负载平衡与邮件服务等开发应用系统常用的功能;而且它还在不断的改进和完善中,任何一个感兴趣的程序员都可以更改它或在其中加入新的功能。
Tomcat 是一个小型的轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用,是开发和调试JSP 程序的首选。对于一个初学者来说,可以这样认为,当在一台机器上配置好Apache 服务器,可利用它响应对HTML 页面的访问请求。实际上Tomcat 部分是Apache 服务器的扩展,但它是独立运行的,所以当你运行tomcat 时,它实际上作为一个与Apache 独立的进程单独运行的。
Weblogic
WebLogic是用于开发、集成、部署和管理大型分布式Web应用、网络应用和数据库应用的Java应用服务器。将Java的动态功能和Java Enterprise标准的安全性引入大型网络应用的开发、集成、部署和管理之中。
Ant
Maven
Apache Ant
• Ant 没有正式的约定如一个一般项目的目录结构,你必须明确的告诉 Ant 哪里去找源代码,哪里放置输出
• Ant 是程序化的,你必须明确的告诉 Ant 做什么,什么时候做。你必须告诉它去编译,然后复制,然后压缩。
• Ant 没有生命周期,你必须定义目标和目标之间的依赖。你必须手工为每个目标附上一个任务序列。
Apache Maven
• Maven 拥有约定,因为你遵循了约定,它已经知道你的源代码在哪里。它把字节码放到 target/classes ,然后在 target 生成一个 JAR 文件。
• Maven 是声明式的。你需要做的只是创建一个 pom.xml 文件然后将源代码放到默认的目录。Maven 会帮你处理其它的事情。
• Maven 有一个生命周期,当你运行 mvn install 的时候被调用。这条命令告诉 Maven 执行一系列的有序的步骤,直到到达你指定的生命周期。遍历生命周期旅途中的一个影响就是,Maven 运行了许多默认的插件目标,这些目标完成了像编译和创建一个 JAR 文件这样的工作。Maven 以插件的形式为一些一般的项目任务提供了内置的智能。如果你想要编写运行单元测试,
使用过Ant的朋友都会有这样的体会吧。 Ant提供的task级别描述,我们可以通过想写shell一样一个Java项目的build过程来进行描述。我们可以写好一个build.xml 文件,来解决我们在Java程序运行编译过程中需要解决的classpath,以及相关参数的配置问题,只有是项目中的主要结构以及依赖的库不变,我们很少去修改build.xml。但是如果我们要开发一个新的项目即使原有项目的build.xml写的即使再好,其能够复用得模块还是比较少的。特别是对项目的结构进行修改后,想不修改build.xml都很困难。这是因为Ant 所提供的可重用的task粒度太小,虽然灵活性很强,但是我们需要纠缠很多细节的东西。
正如你所在使用Servlet 容器时,并没有告诉它如何去解包WAR文件,在你使用Maven 时,你也不需要告诉Maven 如何build你的项目。 Maven提供了一套抽象层用来分离项目的build 逻辑。 许多人一开始就被Maven所提供的依赖管理(可以通过XML来描述项目所依赖的库的关系)打动,但是使用Maven的主要好处还是它能为提供一个标准的开发构架用来对多个项目进行管理。 依赖管理只是这个标准开发构架所提供的一个副产品。
如果想让Maven实现某个build过程,例如compile, test, install,我们可以通过写plugin的方式,很容易就实现build过程的复用。Maven可以为我们提供一个很舒适的build环境,我们不需要通过build.xml定义繁琐的build过程, 只需要告诉这些build过程的plugin,我现在的文件依赖的那些第三方库,我需要实现什么样的build功能,就足够了。 那些繁琐的路径配置信息,以及复杂的第三方库下载设置,你通通不用考虑, Maven 以及它的plugin都帮你实现了。
Svn
Cvs
Git
streateam
版本库模型(Repository model):描述了多个源码版本库副本间的关系,有客户端/服务器和分布式两种模式。在客户端/服务器模式下,每一用户通过客户端访问位于服务器的主版本库,每一客户机只需保存它所关注的文件副本,对当前工作副本(working copy)的更改只有在提交到服务器之后,其它用户才能看到对应文件的修改。而在分布式模式下,这些源码版本库副本间是对等的实体,用户的机器出了保存他们的工作副本外,还拥有本地版本库的历史信息。
* 并发模式(Concurrency model):描述了当同时对同一工作副本/文件进行更改或编辑时,如何管理这种冲突以避免产生无意义的数据,有排它锁和合并模式。在排它锁模式下,只有发出请求并获得当前文件排它锁的用户才能对对该文件进行更改。而在合并模式下,用户可以随意编辑或更改文件,但可能随时会被通知存在冲突(两个或多个用户同时编辑同一文件),于是版本控制工具或用户需要合并更改以解决这种冲突。因此,几乎所有的分布式版本控制软件采用合并方式解决并发冲突。
* 历史模式(History model):描述了如何在版本库中存贮文件的更改信息,有快照和改变集两种模式。在快照模式下,版本库会分别存储更改发生前后的工作副本;而在改变集模式下,版本库除了保存更改发生前的工作副本外,只保存更改发生后的改变信息。
* 变更范围(Scope of change):描述了版本编号是针对单个文件还是整个目录树。
* 网络协议(Network protocols):描述了多个版本库间进行同步时采用的网络协议。
* 原子提交性(Atomic commit):描述了在提交更改时,能否保证所有更改要么全部提交或合并,要么不会发生任何改变。
* 部分克隆(Partial checkout/clone):是否支持只拷贝版本库中特定的子目录。
名称 | 版本库模型 | 并发模式 | 历史模式 | 变更范围 | 网络协议 | 原子提交性 | 部分克隆 |
CVS | Client-server | Merge | Changeset | File | Pserver,ssh | No | Yes |
SVN | Client-server | 3-way merge, recursive merge, octopus merge | Changeset and Snapshot | Tree | custom (svn), custom (svn) over ssh, HTTP and SSL (usingWebDAV) | Yes | Yes |
Git | Distributed | Merge or lock | Snapshot | Tree | custom, custom over ssh, rsync, HTTP/HTTPS, email, bundles | Yes | No |