iBATIS DataMapper 2.3 开发指南

需积分: 0 117 浏览量更新于2024-07-25 收藏 548KB PDF 举报

"ibatis文档，包括DeveloperGuide，覆盖了iBATIS DataMapper 2.3的主要内容，如安装、升级、配置文件、SQL映射、存储过程、参数映射、结果映射以及缓存等。" iBATIS DataMapper是Java平台上的一个持久层框架，它提供了一种将SQL语句与Java代码分离的方式，使得数据库操作更加灵活和易于维护。本文档主要针对iBATIS 2.3版本，为开发者提供了详细的使用指南。 1. **Introduction** iBATIS DataMapper是iBATIS框架的核心部分，它的主要任务是将Java对象与SQL语句进行映射，简化数据库操作。它允许开发者在XML文件中编写SQL，同时保持业务逻辑和数据访问逻辑的分离。 2. **Installation** 安装iBATIS通常涉及添加相应的JAR文件到项目的类路径中，以及配置相关的数据源和事务管理器。这个过程可能因具体项目环境而异，例如在Web应用中，可能需要在web.xml中配置。 3. **Upgrading from 1.x** 升级到2.3版本时，需要注意新版本可能引入的API变化或配置格式的更新。开发者需要检查并修改现有代码和配置文件以确保兼容性。 4. **The SQLMap XML Configuration File** SQLMap XML配置文件是iBATIS的核心，它定义了数据源、事务管理器、SQL映射和类型别名等。文件中的元素包括： - `<properties>`：用于加载外部属性文件，提供动态配置的能力。 - `<settings>`：设置iBATIS的行为，如开启或关闭缓存。 - `<resultObjectFactory>`：自定义结果对象工厂，控制对象的创建方式。 - `<typeAlias>`：定义类型别名，简化类引用。 - `<transactionManager>`：配置事务管理器，如JDBC或JTA。 - `<dataSource>`：配置数据源，连接数据库的信息。 - `<sqlMap>`：定义SQL映射，包含多个MappedStatement。 5. **The SQLMap XML File and MappedStatements** SQL映射文件包含了具体的SQL语句和结果映射。MappedStatements定义了SQL语句的ID、类型（INSERT、UPDATE、DELETE、SELECT）、参数和结果集。 6. **Statement Types** 包括动态SQL、重用SQL片段、自动增长键、存储过程等，提供了丰富的SQL支持。 7. **Parameter Maps and Inline Parameters** 参数映射定义了如何将Java对象的属性绑定到SQL语句的参数。Inline Parameter Maps允许在SQL语句中直接嵌入Java对象属性。 8. **Result Maps** 结果映射定义了如何将查询结果转换为Java对象，包括基本类型、复杂对象、集合和复合键。 9. **Caching Mapped Statement Results** iBATIS支持缓存，可以提高查询性能，但需合理配置以避免数据一致性问题。以上内容仅是iBATIS DataMapper 2.3 Developer Guide的部分概述，实际使用时，开发者还需要深入理解每个部分的细节，以充分利用iBATIS的功能，提高开发效率和代码质量。

Developer Guide iBATIS Data Mapper 2.3

the object through its normal means (class.newInstance()). If you return null from a request to create

java.util.Collection or java.util.List, then iBATIS will create

java.util.ArrayList. If you return null from a request to create java.util.Set, then iBATIS

will create java.util.HashSet. iBATIS passes the current statement id to let you know the context in

which the object create is requested.

The <typeAlias> Element

The typeAlias element simply allows you to specify a shorter name to refer to what is usually a long, fully

qualified classname. For example:

There are some predefined aliases used in the SQL Map Config file. They are:

Transaction Manager Aliases

JDBC

JTA

EXTERNAL

com.ibatis.sqlmap.engine.transaction.jdbc.JdbcTransactionConfig

com.ibatis.sqlmap.engine.transaction.jta.JtaTransactionConfig

com.ibatis.sqlmap.engine.transaction.external.ExternalTransactionConfig

Data Source Factory Aliases

SIMPLE

DBCP

JNDI

com.ibatis.sqlmap.engine.datasource.SimpleDataSourceFactory

com.ibatis.sqlmap.engine.datasource.DbcpDataSourceFactory

com.ibatis.sqlmap.engine.datasource.JndiDataSourceFactory

The <transactionManager> Element

1.0 Conversion Note: Data Mapper 1.0 allowed multiple datasources to be configured. This became

cumbersome and introduced some bad practices. Therefore 2.0 only allows a single datasource. For

multiple deployments/configurations it is recommended that you use multiple properties files that are

either configured differently by the system, or passed in as a parameter when building the SQL Map (see

the java API section below).

The <transactionManager> element allows you to configure the transaction management services for an

SQL Map. The type attribute indicates which transaction manager to use. The value can either be a class

name or a type alias. The three transaction managers included with the framework are: JDBC, JTA and

EXTERNAL.

JDBC - This allows JDBC to control the transaction via the usual Connection commit() and

rollback() methods.

JTA - This transaction manager uses a JTA global transaction such that the SQL Map activities can

be included as part of a wider scope transaction that possibly involves other databases or

transactional resources. This configuration requires a UserTransaction property set to locate the

user transaction from a JNDI resource. See the JNDI datasource example below for an example of

this configuration.

EXTERNAL – This allows you to manage transactions on your own. You can still configure a

data source, but transactions will not be committed or rolled back as part of the framework

lifecycle. This means that some part of your application external to Data Mapper must manage the

transactions. This setting is also useful for non-transactional databases (e.g. Read-only).

The <transactionManager> element also allows an optional attribute commitRequired that can be true or

false. Normally iBATIS will not commit transactions unless an insert, update, or delete operation has been

performed. This is true even if you explicitly call the commitTransaction() method. This behavior

creates problems in some cases. If you want iBATIS to always commit transactions, even if no insert,

http://ibatis.apache.org by Clinton Begin

Developer Guide iBATIS Data Mapper 2.3

update, or delete operation has been performed, then set the value of the commitRequired attribute to true.

Examples of where this attribute is useful include:

1. If you call a stored procedures that updates data as well as returning rows. In that case you would

call the procedure with the queryForList() operation – so iBATIS would not normally commit the

transaction. But then the updates would be rolled back.

2. In a WebSphere environment when you are using connection pooling and you use the JNDI

<dataSource> and the JDBC or JTA transaction manager. WebSphere requires all transactions on

pooled connections to be committed or the connection will not be returned to the pool.

Note that the commitRequired attribute has no effect when using the EXTERNAL transaction manager.

Some of the transaction managers allow extra configuration properties. The following table shows extra

properties that are available for the various transaction managers:

Transaction

Manager

Properties

EXTERNAL

Property Description

DefaultAutoCommit If “true”, then setAutoCommit(true) will be called on the

underlying connection for each transaction if that is not the

value supplied by the underlying datasource.

If “false” or unspecified, then setAutoCommit(false) will be

called on the underlying connection for each transaction if

that is not the value supplied by the underlying datasource.

This behavior can be overridden with the

“SetAutoCommitAllowed” property.

SetAutoCommitAllowed If “true” or unspecified, then the behavior specified in the

“DefaultAutoCommit” property will occur.

If “false”, then iBATIS will not call setAutoCommit in any

case – this is useful in environments like WebSphere where

the setAutoCommit method should not be called in any

circumstance.

JTA

Property Description

UserTransaction This property is required.

The value of the user transaction. Note that in many cases

this should be set to “java:comp/UserTransaction”

The <dataSource> Element

Included as part of the transaction manager configuration is a dataSource element and a set of properties to

configure a DataSource for use with your SQL Map. There are currently three datasource factories

provided with the framework, but you can also write your own. The included DataSourceFactory

implementations are discussed in further detail below and example configurations are provided for each.

http://ibatis.apache.org by Clinton Begin

Developer Guide iBATIS Data Mapper 2.3

SimpleDataSourceFactory

The SimpleDataSource factory provides a basic implementation of a pooling DataSource that is

ideal for providing connections in cases where there is no container provided DataSource. It is

based on the iBATIS SimpleDataSource connection pool implementation.

<property name="JDBC.ConnectionURL"

value="jdbc:postgresql://server:5432/dbname"/>

</dataSource>

</transactionManager>

Note that any property prefixed with “Driver.” will be added as a property to the underlying JDBC

driver.

DbcpDataSourceFactory

This implementation uses Jakarta DBCP (Database Connection Pool) to provide connection

pooling services via the DataSource API. This DataSource is ideal where the application/web

container cannot provide a DataSource implementation, or you’re running a standalone

application. IBATIS provides direct access to setting the properties of a DBCP datasource by

allowing you to specify any DBCP property name you desire in the configuration. For example:

<!-- Use of the validation query can be problematic.

If you have difficulty, try without it. -->

</datasource>

</transactionManager>

http://ibatis.apache.org by Clinton Begin

Developer Guide iBATIS Data Mapper 2.3

You can see all available properties here:

http://jakarta.apache.org/commons/dbcp/configuration.html

Note that any property prefixed with “Driver.” will be added as a property to the underlying JDBC

driver as shown above.

iBATIS also supports a less flexible legacy configuration option as show below. However, we

recommend that you use the configuration option shown above.

<!-- Use of the validation query can be problematic.

If you have difficulty, try without it. -->

</datasource>

</transactionManager>

The properties shown are the only properties recognized by iBATIS when using the legacy

configuration option. Note that any property prefixed with “Driver.” will be added as a property to

the underlying JDBC driver as shown above.

JndiDataSourceFactory

This implementation will retrieve a DataSource implementation from a JNDI context from within

an application container. This is typically used when an application server is in use and a

container managed connection pool and associated DataSource implementation are provided. The

standard way to access a JDBC DataSource implementation is via a JNDI context.

JndiDataSourceFactory provides functionality to access such a DataSource via JNDI. The

configuration parameters that must be specified in the datasource stanza are as follows:

</dataSource>

</transactionManager>

The above configuration will use normal JDBC transaction management. But with a container

managed resource, you might also want to configure it for global transactions as follows:

</dataSource>

</transactionManager>

Notice the UserTransaction property that points to the JNDI location where the UserTransaction

instance can be found. This is required for JTA transaction management so that your SQL Map

take part in a wider scoped transaction involving other databases and transactional resources.

http://ibatis.apache.org by Clinton Begin

剩余71页未读，继续阅读

u010876169

粉丝: 0
资源: 1

iBATIS DataMapper 2.3 开发指南

iBATIS-SqlMaps-2中文文档：数据库操作指南

Ibatis入门教程：快速掌握数据库操作

MyBatis3用户指南：构建SqlSessionFactory与XML映射配置

Ibatis文档

iBatis文档

ibatis 文档

ibatis api,ibatis文档,ibatis说明文档

ibatis 文档查询

java Ibatis文档

iBatis文档\ibatis.doc

最新资源