相对Hibernate和Apache OJB 等“一站式”ORM解决方案而言，ibatis 是一种“半

自动化”的ORM实现。

以前ORM的框架（hibernate,ojb）的局限：

1． 系统的部分或全部数据来自现有数据库，处于安全考虑，只对开发团队提供几条Select SQL（或存储过程）以获取所需数据，具体的表结构不予公开。

2． 开发规范中要求，所有牵涉到业务逻辑部分的数据库操作，必须在数据库层由存储过程实现（就笔者工作所面向的金融行业而言，工商银行、中国银行、交通银行，都在开发规范中严格指定）

3． 系统数据处理量巨大，性能要求极为苛刻，这往往意味着我们必须通过经过高度优化的SQL语句（或存储过程）才能达到系统性能设计指标。

ibatis 的着力点:

在于POJO 与SQL之间的映射关系。也就是说，ibatis

并不会为程序员在运行期自动生成SQL 执行。具体的SQL 需要程序员编写，然后通过映射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定POJO。

Ibatis与Hibernate的区别：

Hibernate提供了全面的数据库封装机制的“全自动化”ORM 实现而言，“全自动”ORM 实现了POJO 和数据库表之间的映射，以及SQL 的自动生成和执行，而ibatis 的着力点，则在于POJO 与SQL之间的映射关系。也就是说，ibatis并不会为程序员在运行期自动生成SQL 执行。具体的SQL 需要程序员编写，然后通过映射配置文件，将SQL所需的参数，以及返回的结果字段映射到指定POJO。

ibatis配置文件:

<?xml version="1.0" encoding="UTF-8" ?>

<!DOCTYPE sqlMapConfig

PUBLIC "-//iBATIS.com//DTD SQL Map Config 2.0//EN"

"http://www.ibatis.com/dtd/sql-map-config-2.dtd">

<sqlMapConfig>

<settings ⑴

cacheModelsEnabled="true"

enhancementEnabled="true"

lazyLoadingEnabled="true"

errorTracingEnabled="true"

maxRequests="32"

maxSessions="10"

maxTransactions="5"

useStatementNamespaces="false"

/>

<transactionManager type="JDBC"> ⑵

<dataSource type="SIMPLE"> ⑶

<property name="JDBC.Driver"

value="com.p6spy.engine.spy.P6SpyDriver"/>

<property name="JDBC.ConnectionURL"

value="jdbc:mysql://localhost/sample"/>

<property name="JDBC.Username" value="user"/>

<property name="JDBC.Password" value="mypass"/>

<property name="Pool.MaximumActiveConnections"

value="10"/>

<property name="Pool.MaximumIdleConnections" value="5"/>

<property name="Pool.MaximumCheckoutTime"

value="120000"/>

<property name="Pool.TimeToWait" value="500"/>

<property name="Pool.PingQuery" value="select 1 from

ACCOUNT"/>

<property name="Pool.PingEnabled" value="false"/>

<property name="Pool.PingConnectionsOlderThan"

value="1"/>

<property name="Pool.PingConnectionsNotUsedFor"

value="1"/>

</dataSource>

</transactionManager>

<sqlMap resource="com/ibatis/sample/User.xml"/> ⑷

<sqlMap resource="com/ibatis/sample/Address.xml"/>

</sqlMapConfig>

⑴Settings 节点 参数

描述

cacheModelsEnabled

是否启用SqlMapClient上的缓存机制。建议设为"true"

enhancementEnabled

是否针对POJO启用字节码增强机制以提升getter/setter的调用效能，避免使用JavaReflect所带来的性能开销。同时，这也为Lazy Loading带来了极大的性能提升。建议设为"true"

errorTracingEnabled

是否启用错误日志，在开发期间建议设为"true"以方便调试

lazyLoadingEnabled

是否启用延迟加载机制，建议设为"true"

maxRequests

最大并发请求数（Statement并发数）

maxTransactions

最大并发事务数

maxSessions

最大Session 数。即当前最大允许的并发SqlMapClient数。maxSessions设定必须介于maxTransactions和maxRequests之间，即 maxTransactions<maxSessions=<maxRequests

useStatementNamespaces

是否使用Statement命名空间。这里的命名空间指的是映射文件中，sqlMap节点的namespace属性，如在上例中针对t_user

表的映射文件sqlMap节点：

<sqlMap namespace="User">

这里，指定了此sqlMap节点下定义的操作均从属于"User"命名空间。

在useStatementNamespaces="true"的情况下，Statement调用需追加命名空间，如：sqlMap.update("User.updateUser",user);否则直接通过Statement名称调用即可，如：sqlMap.update("updateUser",user);

但请注意此时需要保证所有映射文件中，Statement定义无重名。

⑵ transactionManager节点

transactionManager 节点定义了ibatis 的事务管理器，目前提供了以下几种选择：

Ø JDBC

通过传统JDBC Connection.commit/rollback实现事务支持。

Ø JTA

使用容器提供的JTA服务实现全局事务管理。

Ø EXTERNAL

外部事务管理，如在EJB中使用ibatis，通过EJB的部署配置即可实现自动的事务管理机制。此时ibatis 将把所有事务委托给外部容器进行管理。此外，通过Spring 等轻量级容器实现事务的配置化管理也是一个不错的选择。关于结合容器实现事务管理，参见“高级特性”中的描述。

⑶ dataSource节点

dataSource从属于transactionManager节点，用于设定ibatis运行期使用的DataSource属性。

type属性： dataSource节点的type属性指定了dataSource的实现类型。可选项目：

Ø SIMPLE：

SIMPLE是ibatis内置的dataSource实现，其中实现了一个简单的数据库连接池机制，对应ibatis 实现类为com.ibatis.sqlmap.engine.datasource.SimpleDataSourceFactory。

Ø DBCP:

基于Apache DBCP 连接池组件实现的DataSource 封装，当无容器提供DataSource 服务时，建议使用该选项，对应ibatis 实现类为com.ibatis.sqlmap.engine.datasource.DbcpDataSourceFactory。

Ø JNDI：

使用J2EE 容器提供的DataSource 实现，DataSource 将通过指定的JNDI Name 从容器中获取。对应ibatis 实现类为com.ibatis.sqlmap.engine.datasource.JndiDataSourceFactory。

dataSource的子节点说明（SIMPLE&DBCP）：

参数

描述

JDBC.Driver

JDBC 驱动。如：com.microsoft.jdbc.sqlserver.SQLServerDriver

JDBC.ConnectionURL

数据库URL。如：

jdbc:microsoft:sqlserver://localhost:1433;databaseName=ibatis如果用的是SQLServer JDBC Driver，需要在url后追加SelectMethod=Cursor以获得JDBC事务的多Statement支持。

JDBC.Username

数据库用户名

JDBC.Password

数据库用户密码

Pool.MaximumActiveConn

ections

数据库连接池可维持的最大容量。

Pool.MaximumIdleConnec

tions

数据库连接池中允许的挂起（idle）连接数。

以上子节点适用于SIMPLE 和DBCP 模式，分别针对SIMPLE 和DBCP 模式的DataSource私有配置节点如下：

SIMPLE:

Pool.MaximumCheckoutTime

数据库联接池中，连接被某个任务所允许占用的最大时间，如果超过这个时间限定，连接将被强制收回。（毫秒）

Pool.TimeToWait

当线程试图从连接池中获取连接时，连接池中无可用连接可供使用，此时线程将进入等待状态，直到池中出现空闲连接。此参数设定了线程所允许等待的最长时间。（毫秒）

Pool.PingQuery

数据库连接状态检测语句。某些数据库在连接在某段时间持续处于空闲状态时会将其断开。而连接池管理器将通过此语句检测池中连接是否可用。检测语句应该是一个最简化的无逻辑SQL。如“select 1 from t_user”，如果执行此语句成功，连接池管理器将认为此连接处于可用状态

Pool.PingEnabled

是否允许检测连接状态。

Pool.PingConnectionsOlderThan

对持续连接时间超过设定值（毫秒）的连接进行检测。

Pool.PingConnectionsNotUsedFor

对空闲超过设定值（毫秒）的连接进行检测。

DBCP:

Pool.MaximumWait

当线程试图从连接池中获取连接时，连接池中无可用连接可供使用，此时线程将进入等待状态，直到池中出现空闲连接。此参数设定了线程所允许等待的最长时间。（毫秒）

Pool.ValidationQuery

数据库连接状态检测语句。某些数据库在连接在某段时间持续处于空闲状态时会将其断开。而连接池管理器将通过此语句检测池中连接是否可用。检测语句应该是一个最简化的无逻辑SQL。如“select 1 from t_user”，如果执行此语句

成功，连接池管理器将认为此连接处于可用状态。

Pool.LogAbandoned

当数据库连接被废弃时，是否打印日志。

Pool.RemoveAbandonedTimeout

数据库连接被废弃的最大超时时间

Pool.RemoveAbandoned

当连接空闲时间超过RemoveAbandonedTimeout时，是否将其废弃。

JNDI:

由于大部分配置是在应用服务器中进行，因此ibatis中的配置相对简单，下面是分别使用JDBC和JTA事务管理的JDNI配置：

使用JDBC事务管理的JNDI DataSource配置

<transactionManager type="JDBC" >

<dataSource type="JNDI">

<property name="DataSource" value="java:comp/env/jdbc/myDataSource"/>

</dataSource>

</transactionManager>

<transactionManager type="JTA" >

<property name="UserTransaction" value="java:/ctx/con/UserTransaction"/>

<dataSource type="JNDI">

<property name="DataSource" value="java:comp/env/jdbc/myDataSource"/>

</dataSource>

</transactionManager>

⑷ sqlMap节点

sqlMap 节点指定了映射文件的位置，配置中可出现多个sqlMap 节点，以指定项目内所包含的所有映射文件。

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE sqlMap PUBLIC "-//iBATIS.com//DTD SQL Map 2.0//EN"

"http://www.ibatis.com/dtd/sql-map-2.dtd">

<sqlMap namespace="映射文件名称：User">

<typeAlias alias="user" type="com.ibatis.sample.User"/> 给对应的类取别名

<cacheModel id="userCache" type="LRU">

<flushInterval hours="24"/> 设定缓存有效期

<flushOnExecute statement=" updateUser"/>

指定执行特定Statement时，将缓存清空。如updateUser操作将更新数据库中的用户信息，这将导致缓存中的数据对象与数据库中的实际数据发生偏差，因此必须将缓存清空以避免脏数据的出现。

<property name="size" value="1000" /> CacheModel中最大容纳的数据对象数量

</cacheModel>

申明了一个名为"userCache"的cacheModel，之后可以在Statement申明中对其进行引用：例如：

<select id="getUser" parameterClass="java.lang.String" resultClass="user"

cacheModel="userCache">

<select id="" parameterClass="java.lang.String" resultClass="user">

<![CDATA[    可以避免SQL 中与XML 规范相冲突的字符对XML映射文件的合法性造成影响。

SQL语句

]]>

</select>

< update id=" " parameterClass="java.lang.String" >

<![CDATA[

SQL语句

]]>

</ update >

< insert id=" " parameterClass="java.lang.String" >

<![CDATA[

SQL语句

]]>

</ insert >

< delete id="" parameterClass="java.lang.String" >

<![CDATA[

SQL语句

]]>

</ delete >

</sqlMap>

需要一个JAVABEAN：有getter和setter方法

如何读取配置文件：

       public class SQLMapper {

       public static SqlMapClient sqlMapper;

       static{

              String resource = "org/lzp/xml/SqlMapConfig.xml";指明了配置文件的相对路径

              try {

                     Reader reader = Resources.getResourceAsReader(resource);

           //ibatis2.0

           /* XmlSqlMapClientBuilder xmlBuilder =

new XmlSqlMapClientBuilder();

sqlMapper = xmlBuilder.buildSqlMap(reader);

*/

//ibatis1.0

                     sqlMapper = SqlMapClientBuilder.buildSqlMapClient(reader);

              } catch (Exception e) {

                     e.printStackTrace();

              }

       }

}

SqlMapClient是ibatis运作的核心，所有操作均通过SqlMapClient实例完成。例如：

sqlMapper.insert("名称", 参数);

sqlMapper提供了众多数据操作方法，下面是一些常用方法的示例，具体说明文档请参见ibatis java doc，或者ibatis官方开发手册。

Statement配置：

Statement配置包含了数个与SQL Statement相关的节点，分别为：

u statement: 最为通用，它可以替代其余的所有节点。

u insert

u delete

u update

u select

u procedure

参数描述：可以是类、基本数据类型和MAP进行传值

参数

描述

parameterClass

参数类。指定了参数的完整类名（包括包路径）。

可通过别名避免每次重复书写冗长的类名。

resultClass

结果类。指定结果类型的完整类名（包括包路径）

可通过别名避免每次重复书写冗长的类名。

parameterMap

参数映射，需结合parameterMap节点对映射关系加以定义。对于存储过程之外的statement而言，建议使用parameterClass作为参数配置方式，一方面避免了参数映射配置工作，另一方面其性能表现也更加出色。

resultMap

结果映射，需结合resultMap节点对映射关系加以定义。

cacheModel

statement对应的Cache模块。

动态映射：

<select id="getUsers" parameterClass="user" resultClass="user">

Select id,name,sex from t_user

<dynamic prepend="WHERE">

<isNotEmpty prepend="AND" property="name">

(name like #name#)

</isNotEmpty>

<isNotEmpty prepend="AND" property="address">

(address like #address#)

</isNotEmpty>

</dynamic>

</select>

Ø 一元判定: 是针对属性值本身的判定，如属性是否为NULL，是否为空值等。

一元判定节点有：

节点名

描述

<isPropertyAvailable>

参数类中是否提供了此属性

<isNotPropertyAvailable>

与<isPropertyAvailable>相反

<isNull>

属性值是否为NULL

<isNotNull>

与<isNull>相反

<isEmpty>

如果属性为Collection或者String，其size是否<1，

如果非以上两种类型，则通过

String.valueOf(属性值)

获得其String类型的值后，判断其size是否<1

<isNotEmpty>

与<isEmpty>相反。

Ø 二元判定

二元判定有两个判定参数，一是属性名，而是判定值，如

<isGreaterThan prepend="AND" property="age" compareValue="18">

(age=#age#)

</isGreaterThan>

其中，property="age"指定了属性名”age”，compareValue=”18”指明了判定值为”18”。上面判定节点isGreaterThan 对应的语义是：如果age 属性大于

18(compareValue)，则在SQL中加入(age=#age#)条件。

二元判定节点有：

节点名

属性值与compareValues的关系

<isEqual>

相等。

<isNotEqual>

不等。

<isGreaterThan>

大于

<isGreaterEqual>

大于等于

<isLessThan>

小于

<isLessEqual>

小于等于

通常，我们为了避免内存溢出等问题，需要设置环境变量
JAVA_OPTS    -Xms256M -Xmx512M 等，【对于服务器，一般都设置成一样的】
但是有的时候可能这样的设置还会不行(比如，当Server应用程序加载较多类时，即jvm加载类时，永久域中的对象急剧增加，从而使jvm不断调整永久域大小，为了避免调整)，你可以使用更多的参数配置，如： java -Xms512m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=128m
其中，使用   -XX:MaxPerSize标志来增加永久域的大小，-XX:PerSize标志设置初始值

-XX

基于 Sun 的 Java 2 Standard Edition（J2SE）5 有生成垃圾回收功能，这允许分隔内存池以包含不同时效的对象。垃圾回收循环根据时效收集与其他对象彼此独立的对象。使用其他参数，您可以单独设置内存池的 大小。为了实现更好的性能，您应该对包含短期存活对象的池的大小进行设置，以使该池中的对象的存活时间不会超过一个垃圾回收循环。新生成的池的大小由 NewSize 和 MaxNewSize 参数确定。

-XX:NewSize (lower bound)

-XX:MaxNewSize (upper bound)

-XX:SurvivorRatio=NewRatioSize 

-XX:NewSize 320m 此值设大可调大新对象区，减少Full GC次数

-XX:+UseParNewGC ：缩短minor收集的时间 可用来设置并行收集【多CPU】

-XX:+ParallelGCThreads 可用来增加并行度【多CPU】

-XX:+UseParallelGC 设置后可以使用并行清除收集器【多CPU】-Xss：每个线程的Stack大小


-verbose:gc 显示垃圾收集信息
-Xloggc:gc.log 指定垃圾收集日志文件
刚刚了解到的一些参数（待实践测试）
-Xmn：young generation的heap大小，一般设置为Xmx的3、4分之一


-XX:+UseConcMarkSweepGC ：缩短major收集的时间
提示：此选项在Heap Size 比较大而且Major收集时间较长的情况下使用更合适



下面的命令把整个堆设置成128m，新域比率设置成3，即新域与旧域比例为1：3，新域为堆的1/4或32M：



java –Xms128m –Xmx128m –XX:NewRatio =3

缺省值为：NewSize=2m MaxNewSize=32m SurvivorRatio=2。但是，如果 JVM 的堆大小大于 1GB，则应该使用值：-XX:newSize=640m -XX:MaxNewSize=640m -XX:SurvivorRatio=16，或者将堆的总大小的 50% 到 60% 分配给新生成的池。

          举例：永久域默认大小为4m。运行程序时，jvm会调整永久域的大小以满足需要。每次调整时，jvm会对堆进行一次完全的垃圾收集。

如果你想创建一个只包含一个源程序文件的简单程序，那么你只需要编译、连接那一个文件就可以了。如果是一个团队项目组，有着许多甚至上千个源程序文件，那么要创建一个可执行程序的过程就变得更复杂、更耗时。你必须用各种各样的组件将程序逐步建立起来。

在微软或其它一些软件公司中惯例是：每日构造并做“冒烟测试”。每天都对已完成的源程序进行编译，然后连接组合成可执行的程序，并做“冒烟测试”，以简单的检查该执行程序在运行时是否会“冒烟”。

带来的好处

虽然这是一个非常简单的过程，但却有非常重要的意义：

1、能最小化集成风险

项目组可能遇到的一个很大的风险是，项目组成员根据不同的系统功能各自开发不同的代码，但是当这些代码集成为一个系统的时候，也许系统完成不了预期的功能。这种风险的发生取决于项目中的这种不兼容性多久才被发现，由于程序界面已经发生了变化，或者系统的主要部分已经被重新设计和重新实现了，相应的排错工作将非常困难和耗时。极端情况下，集成的错误可能回导致项目被取消掉。每日构造和冒烟测试可以使这种集成错误变得非常小，而且便于解决，防止了很多集成问题的产生。

2、能减小产品低质量的风险

    这种风险是和集成不成功、集成出错相关联的。每天对集成的代码做一些少量的冒烟测试，即可杜绝项目中那些基本的质量问题。通过这种方式，使系统达到一种周知的良好状态，维护这样的系统可以防止系统逐步恶化到耗费大量时间排查质量问题的地步。

3、能简单化错误诊断

当系统每天都进行build和测试时，系统任何一天发生的错误都能够变得十分精细，便于排查。比如在17日系统还运行正常，18日就出错了，那么只需要检查这两次build之间的代码变化就可以了。

4、能极大鼓舞项目组的士气

看到产品的不断成长，能够极大的鼓舞项目组的士气，有时甚至不管这个产品到底用来做什么。开发人员可能会为系统显示了一个矩形而感到激动。通过每日构造，产品每天进步一点点，保证项目士气的持续高涨。

进行每日构造和冒烟测试

虽然说这是一个简单枯燥的活，每天进行build，每天进行测试，但也有着一些值得注意的细节：

1、每天坚持

每日构造，最重要的就是“每日”。如Jim McCarthy所说，把每日构造看作是项目的“心跳”，没有“心跳”的话，项目也就死了(Dynamics of Software Development, Microsoft Press, 1995)。Michael Cusumano and Richard W. Selby描述了另外一种隐含的比喻，把每日构造比作项目的“同步脉冲”(Microsoft Secrets, The Free Press, 1995)。 不同开发人员写的代码在他们的“脉冲”之间肯定都会存在“同步”的差异，但是必须有这样一个“同步脉冲”，使得这些代码能够组合为一个整体。当项目组坚持每天把这些不同的“脉冲”组合到一起的时候，开发人员脱离整体的情况就会得到极大程度的杜绝。

有些项目组把这一过程简化为“每周build一次”。这样带来的问题是，某一次build失败后，可能要回溯好几周才能找到原因。如果这种情况发生的话，已经得不到经常build带来的好处了。

2、严格检查每一次build

要保证每一次build的成功，就必须保证build后的结果（也可称为build）是可以正常运行的，如果build不可运行，那么本次build被认为是不成功的，同时应该将修复此次build的工作提高到项目组最高级别来处理。

对于如何衡量一个build，每一个项目组都会定义一些自己的标准，这些标准需要设定一个严格的质量级别来处理那些特别严重的缺陷，同时也需要具有一定的伸缩性来忽略掉那些微不足道的缺陷，一些不适当的关心也许会使整个过程举步为艰。

一个好的build起码应该具备以下条件：

●能够成功编译所有的文件、库，以及其它相关组件；

●能够成功链接所有的文件、库，以及其它相关组件；

●不能存在任何使得系统无法运行或者运行出错的高级别故障；

●当然，必须通过冒烟测试

3、每天进行冒烟测试

冒烟测试应该是对整个系统流程从输入到输出的完整测试。测试不必是面面俱到的，但是应该能够发现系统中较大的问题。冒烟测试应该是足够充分的，通过了冒烟测试的build就可以认为是经过充分测试、足够稳定的。

不进行冒烟测试的build是没有太大价值的。冒烟测试就像一个哨兵，在阻止着产品质量恶化和集成问题的产生，不进行冒烟测试，每日构造可能会变成浪费时间的练习。

冒烟测试必须随着系统的扩充而扩充。最初，冒烟测试可能是非常简单的，比如验证系统是否会打印“Hello World”，随着系统功能的扩充，冒烟测试需要越来越充分。最初的冒烟测试也许只需要几秒钟来执行，逐渐地，测试可能会花费30分钟，1小时，甚至更长。

4、建立一个专门的build小组

    在很多项目组，维护每日构造，并更新冒烟测试用例，会耗费一个人工作的大部分时间。因此在一些大的项目中，这项工作独立成不止一个人来完成的全职工作。比如在 Windows NT 3.0的研发中，就有一个由四个全职人员组成的专门的build小组(Pascal Zachary, Showstopper!, The Free Press, 1994)。

5、为build增加修订，如果这样做有意义的话

    一般开发人员不会每天都经常向系统中快速的增加实际的代码，通常是每隔几天，他们在开发好完成某个功能的一套代码以后，然后集成到整个系统中。

6、规定一些导致build失败的惩罚措施

很多执行每日构造的项目组都会规定一些惩罚措施，来惩罚那些导致build失败的行为。从最开始，项目组成员就清楚的知道，build的正常执行是项目组的头等大事。一个失败的build是项目组的意外，无法成为项目组工作的准则。必须坚持：导致build失败的同事，必须停下手中的工作，首先来解决build失败的问题。如果一个项目组的build经常失败的话，久而久之的，再来谈build的正确性就没有意义了。

有种轻松的惩罚措施，能够突出解决问题的优先性。Some groups give out lollipops to each "sucker" who breaks the build. This developer then has to tape the sucker to his office door until he fixes the problem. 有些项目组会惩罚犯错的同事戴上山羊角，或者向一个项目基金捐献5块钱。

有些项目组对此的惩罚就有点残酷了。微软的开发人员，在一些知名度很高、很重要的产品如Windows NT，Windows 95，Excel等产品后期研发中，被要求随时带着寻呼机，如果你的代码导致build失败的话，即使是凌晨3点钟，也会要求你立即来处理这个问题。

7、即使在压力下也需坚持每日构造和冒烟测试

当项目进度的压力越来越大时，维护每日构造的工作看起来有些浪费时间，但是恰恰相反。在压力之下，开发人员丢掉一些平时的规定，会采用一些设计和实现的捷径，这在平时压力较小的环境下一般时不会用的。代码的review和单元测试也可能会比平时粗心一些，这些代码的状态变化也会比平时快很多。

为防止这种情况的出现，每日构造会坚持相关的规定，让压力下的项目保持在正轨上。代码仍然每天在不断变化，但是构造过程使得这种变化每天都可控。

谁能够从每日构造这种过程中得到好处呢？一些开发人员会抗议说，由于他们的项目太大，每天进行build是没有实际意义的。但是为什么现在最复杂的软件项目组却能够成功的执行每日构造的制度呢？本文首发时，Windows NT包括了560万行代码、分布在4万个源程序文件中，项目组仍然可以坚持每日构造。

Perl 是一种能完成任务的语言。

当然，如果你的工作就是写程序，那么从理论上来讲，你可以使用任何“完整”的计算机语言来完成任务。但是从我们的经验来看，计算机语言的区别很大程度上不在它能干什么，而是在它做事情的时候是否简单。从一个极端来说，那些所谓的第四代语言做某些事情的时候相当容易，但是做其它一些事情的时候几乎不可能。从另外一个极端来看，那些所谓的工业级的语言在做任何事情的时候都几乎一样困难。

Perl 是不同的语言。从一开始，Perl 就设计成可以把简单工作简单化，同时又不失去处理困难问题能力的语言。

那什么是“简单工作”呢？当然就是那些你每天都要干的。你需要一种可以很容易操作数字，文本，文件和目录，计算机和网络，特别是程序的语言。这种语言应该很容易运行外部的程序并且扫描这些程序的输出获取感兴趣的东西。而且它还应该很容易能把这些你感兴趣的东西交给其它程序做特殊的处理。当然，这种语言还应该很容易在任何现代的操作系统上可以移植地编译和运行。

Perl 做到了上述所有需求，甚至更多。

Perl 最初是当做一种 Unix 的胶水语言设计的，但是她早就移植到大多数其它操作系统里了。因为 Perl 几乎可以在任何地方运行，所以 Perl 可以说是当今最具有移植性的编程环境。要想写可移植的 C/C++ 程序，你得在程序里加上一大堆 #ifdef 标签来区分不同的系统。要想写可移植的 Java 程序，你必须理解每种新的 Java 实现的特质。要想写可移植的

shell，你可能要记住每条命令在每种操作系统上的语法，走运的时候你可能可以找到一些公共的东西。而要想写可移植的 Visual Basic 程序，那么你只需要对“移植”有个更灵活的定义就可以了。

我们很高兴的是 Perl 避免了所有这些问题，同时还保留了这些语言中的许多优点，同时还有一些自己的特色。Perl 的特色来自许多方面：它的特性集的工具，Perl 社区的创造性，以及开源运动的大环境。不过，许多这些特性都是混合的东西；Perl 的身世复杂，它总是把事物看成是优点的不同方面，而不是弱点。Perl 是“背黑锅我来”的语言。如果你觉得自己陷入一团乱麻之中，非常渴望自由，那么请使用 Perl。

Perl 是跨文化的。Perl 的爆炸性增长很大程度上是因为那些前 Unix 系统程序员的渴望，他们希望从他们的“老家”带着尽可能多的东西。对于他们而言，Perl 是可移植的 Unix 文化蒸馏器，是"此路不通"的沙漠中的绿洲。从另外一个角度来看，Perl 还可以从另外一个方向运转：在 Windows 上工作的 web 设计者通常会非常开心地发现他们的 Perl 程序可以不加修改地在 Unix 服务器上跑。

对于只是喜欢她的人来说，Perl 是实用抽取和报表语言（Practical Extractoin and Report Language）。对那些热爱她的人而言，她是变态电子垃圾制造者（Pathologically Electric Rubbish Lister）。在少数人眼里，Perl 是毫无意义的重复练习。不过世界需要一点点冗余。

/Files/xiaomage234/perl-zh-third.rar