Ibatis

文档地址：http://ibatis.apache.org/docs/dotnet/datamapper/index.html

一、parameterClass="System.Collections.IDictionary" 和 parameterClass="map" 解释如下：

For your convenience, IDictionary types are aliased by the framework. 
So, map or HashTable can be used in place of System.Collections.Hashtable. 
For a complete list of aliases, see Section 3.6, "Supported Types for Parameter Maps and Result Maps".
refer:http://ibatis.apache.org/docs/dotnet/datamapper/ch03s02.html

二、
ibatis 数组参数 链接  refer:https://blog.csdn.net/bruce128/article/details/22098795

<!--InsertBatch-->
<insert id="InsertBatch" parameterClass="Class" resultClass="int">
INERT INTO TableName
(
Name
,CreateTime)
VALUES
<iterate conjunction="," open="" close="">
(
#[].Name#
, #[].CreateTime#
)
</iterate>
</insert>

数组参数

三、缓存

3.8. Cache Models

Some values in a database are know to change slower than others. To improve performance, many developers like to cache often-used data to avoid making unnecessary trips back to the database. iBATIS provides its own caching system, that you configure through a <cacheModel> element.

The results from a query Mapped Statement can be cached simply by specifying the cacheModel parameter in the statement tag (seen above). A cache model is a configured cache that is defined within your DataMapper configuration file. Cache models are configured using the cacheModel element as follows:

Example 3.51. Configuation a cache using the Cache Model element

<cacheModel id="product-cache" implementation="LRU" readOnly="true" serialize="false">
  <flushInterval hours="24"/>
  <flushOnExecute  statement="insertProduct"/>
  <flushOnExecute  statement="updateProduct"/>
  <flushOnExecute  statement="deleteProduct"/>
  <property name="CacheSize" value="100"/>
</cacheModel>

The cache model above will create an instance of a cache named "product-cache" that uses a Least Recently Used (LRU) implementation. The value of the type attribute is either a fully qualified class name, or an alias for one of the included implementations (see below). Based on the flush elements specified within the cache model, this cache will be flushed every 24 hours. There can be only one flush interval element and it can be set using hours, minutes, seconds or milliseconds. In addition the cache will be flushed whenever the insertProduct, updateProduct, or deleteProduct mapped statements are executed. There can be any number of "flush on execute" elements specified for a cache. Some cache implementations may need additional properties, such as the ‘cache-size' property demonstrated above. In the case of the LRU cache, the size determines the number of entries to store in the cache. Once a cache model is configured, you can specify the cache model to be used by a mapped statement, for example:

Example 3.52. Specifying a Cache Model from a Mapped Statement

<statement id="getProductList" cacheModel="product-cache">
  select * from PRODUCT where PRD_CAT_ID = #value#
</statement>

3.8.1. Read-Only vs. Read/Write

The framework supports both read-only and read/write caches. Read-only caches are shared among all users and therefore offer greater performance benefit. However, objects read from a read-only cache should not be modified. Instead, a new object should be read from the database (or a read/write cache) for updating. On the other hand, if there is an intention to use objects for retrieval and modification, a read/write cache is recommended (i.e. required). To use a read-only cache, set readOnly="true" on the cache model element. To use a read/write cache, set readOnly="false". The default is read-only (true).

框架提供只读和可读写缓存。只读缓存在所有用户（ 用户是什么意思？是per-session吗）之间共享，提供了更好的性能（ 可读写缓存是单用户使用吗？这里用户是怎么区分的呢？）。但是，只读缓存返回的对象不应被修改。跟新后一个新的对象应该从数据库（或一个可读写缓存）读取。另一方面，如果要对对象做遍历、修改，推荐使用读写缓存。

3.8.2. Serializable Read/Write Caches

As you may agree, caching per-session as described above may offer little benefit to global application performance. Another type of read/write cache that can offer a performance benefit to the entire application (i.e. not just per session) is a serializable read/write cache. This cache will return different instances (copies) of the cached object to each session. Therefore each session can safely modify the instance returned. Realize the difference in semantics here, usually you would expect the same instance to be returned from a cache, but in this case you'll get a different one. Also note that every object stored by a serializable cache must be serializable. This means that you will have difficulty using both lazy loading features combined with a serializable cache, because lazy proxies are not serializable. The best way to figure out what combination of caching, lazy loading and table joining is simply to try it out. To use a serializable cache, set readOnly="false" and serialize="true". By default cache models are read-only and non-serializable. Read-only caches will not be serialized (there's no benefit).

 

3.8.3. Cache Implementation

The cache model uses a pluggable framework for supporting different types of caches. The choice of cache is specified in the "implementation" attribute of the cacheModel element as discussed above. The class name specified must be an implementation of the ICacheController interface, or one of the three aliases discussed below. Further configuration parameters can be passed to the implementation via the property elements contained within the body of the cacheModel. Currently there are 3 implementations included with the .NET distribution. These are as follows:

3.8.4. "MEMORY"

The MEMORY cache implementation uses reference types to manage the cache behavior. That is, the garbage collector effectively determines what stays in the cache or otherwise. The MEMORY cache is a good choice for applications that don't have an identifiable pattern of object reuse, or applications where memory is scarce.

The MEMORY implementation is configured as follows:

Example 3.53. Configuring a memory-type cache

<cacheModel id="product-cache" implementation="MEMORY" >
  <flushInterval hours="24"/>
  <flushOnExecute  statement="insertProduct"/>
  <flushOnExecute  statement="updateProduct"/>
  <flushOnExecute  statement="deleteProduct"/>
  <property name="Type" value="WEAK"/>
</cacheModel>

Only a single property is recognized by the MEMORY cache implementation. This property, named 'reference-type' must be set to a value of STRONG, SOFT, or WEAK.

The following table describes the different reference types that can be used for a MEMORY cache.

Table 3.6. Reference types that can be used for a MEMORY cache

Type	Description
WEAK (default)	This reference type is probably the best choice in most cases and is the default if the reference-type is not specified. It will increase performance for popular results, but it will absolutely release the memory to be used in allocating other objects, assuming that the results are not currently in use.
SOFT (currently Java only)	This reference type will reduce the likelihood of running out of memory in case the results are not currently in use and the memory is needed for other objects. However, this is not the most aggressive reference type in that regard and memory still might be allocated and made unavailable for more important objects.
STRONG	This reference type will guarantee that the results stay in memory until the cache is explicitly flushed (e.g. by time interval or flush on execute). This is ideal for results that are: 1) very small, 2) absolutely static, and 3) used very often. The advantage is that performance will be very good for this particular query. The disadvantage is that if the memory used by these results is needed, then it will not be released to make room for other objects (possibly more important objects).

 

3.8.5. "LRU"

The LRU cache implementation uses an Least Recently Used algorithm to determines how objects are automatically removed from the cache. When the cache becomes over full, the object that was accessed least recently will be removed from the cache. This way, if there is a particular object that is often referred to, it will stay in the cache with the least chance of being removed. The LRU cache makes a good choice for applications that have patterns of usage where certain objects may be popular to one or more users over a longer period of time (e.g. navigating back and forth between paginated lists, popular search keys etc.).

The LRU implementation is configured as follows:

Example 3.54. Configuring a LRU type cache

<cacheModel id="product-cache"  implementation="LRU" >
  <flushInterval hours="24"/>
  <flushOnExecute  statement="insertProduct"/>
  <flushOnExecute  statement="updateProduct"/>
  <flushOnExecute  statement="deleteProduct"/>
   <property name="CacheSize" value="100"/>
</cacheModel>

Only a single property is recognized by the LRU cache implementation. This property, named CacheSize must be set to an integer value representing the maximum number of objects to hold in the cache at once. An important thing to remember here is that an object can be anything from a single String instance to an ArrayList of object. So take care not to store too much in your cache and risk running out of memory!

3.8.6. "FIFO"

The FIFO cache implementation uses an First In First Out algorithm to determines how objects are automatically removed from the cache. When the cache becomes over full, the oldest object will be removed from the cache. The FIFO cache is good for usage patterns where a particular query will be referenced a few times in quick succession, but then possibly not for some time later.

The FIFO implementation is configured as follows:

Example 3.55. Configuring a FIFO type cache

<cacheModel id="product-cache" implementation="FIFO" >
  <flushInterval hours="24"/>
  <flushOnExecute  statement="insertProduct"/>
  <flushOnExecute  statement="updateProduct"/>
  <flushOnExecute  statement="deleteProduct"/>
  <property name="CacheSize" value="100"/>
</cacheModel>

Only a single property is recognized by the FIFO cache implementation. This property, named CacheSize must be set to an integer value representing the maximum number of objects to hold in the cache at once. An important thing to remember here is that an object can be anything from a single String instance to an ArrayList of object. So take care not to store too much in your cache and risk running out of memory

readOnly属性：定义是否是只读缓存
true代表只读缓存，这里的只读并不是意味着数据对象一旦放入缓存中就无法再对数据进行修改，而是当数据对象发生变化的时候，如数据对象中的某个属性发生变化，那么数据将从缓存中被废除，下次需要重新从数据库中读取数据，构造新的数据对象。
只读缓存可被多用户共享，提升性能，但是将数据引用直接返回给用户，修改数据导致重新从数据库加载，降低效率。
false代表可读写缓存，返回给你一个原对象的副本，而不是直接将原对象的引用直接返回。可读写缓存可更新。

serialize  是否为全局缓存
true代表全局缓存 ，表示多个session访问该缓存的时候会获得相同内容的不同实例对象，也就是前面说的原对象的副本。所以serialize  值为true的前提是readOnly属性必须为false。

refers：
https://blog.csdn.net/findmyself_for_world/article/details/49976107 
http://ibatis.apache.org/docs/dotnet/datamapper/ch03s08.html

 四、
DomSqlMapBuilder类 加载配置、获取ISqlMapper实例
ISqlMapper类 ：The ISqlMapper instance acts as a facade to provide access the rest of the DataMapper framework. 
翻译： ISqlMapper实例是访问DataMaper框架方法的接口。
理解： ISqlMapper类是框架暴漏给用户的接口方法。


我遇到的问题
# 和 $ 用法问题
Id IN (#IdIn#) IdIn以KeyValuePaire 形式传入为value为字符串 ibatis 尝试把它转化为Id对应的Int型失败。

转载于:https://www.cnblogs.com/fmys/p/9073638.html