Shulou(Shulou.com)06/02 Report--

This article shows you how to analyze the basics of iBATIS ResultMap. The content is concise and easy to understand. It will definitely make your eyes shine. I hope you can gain something through the detailed introduction of this article.

iBATIS ResultMap is a very important content in our study of iBATIS. In my personal opinion, whether we can really use iBATIS well is a key, and this is ResultMap. Literally, it is a mapping of the result set, which assigns a field-by-field mapping of the returned records to the attributes of the object. In fact, if there is no special requirement, we can use ResultClass instead of it, because if the field is the same as the attribute, the query dataset will automatically match the instance object specified by ResultClass. If the field name is not in the attribute, then this field will not be accepted by the returned instance class object, which is equivalent to not querying the same field.

Each ResultMap has its own ID, if you do not configure the use of namespaces in sqlmap.config, then this name is global (this is the same in all iBATIS configuration elements), an important attribute of ResultMap is class, which will determine the class of the instance corresponding to this ResultMap, in other words, its role is to indicate the data type to be mapped by the result set. In the extends property, you can set the ResultMap that it will inherit. If you specify a value for it, it will inherit the mapping configuration field from super Resultmap. Defined as follows:

﹤resultMaps﹥ ﹤resultMap id="DemoResultMap" class="Hashtable"﹥ ﹤/resultMap﹥ ﹤/resultMaps﹥

If you have an XSD schema file configured correctly with iBATIS, you will be prompted that the resultMap definition is incomplete. Yes, the next step is to define the Result element. Each result element defines a mapping of fields to attributes of the data class. Each result element has many attribute parameters, of which property and column are required, and other parameter attributes are optional. So we must define more than one result definition in each resultMap. Usually the following configuration can complete the basic configuration.

﹤resultMaps﹥ ﹤resultMap id="DemoResultMap" class="Hashtable"﹥ ﹤result property="id" column="id"/﹥ ﹤/resultMap﹥ ﹤/resultMaps﹥

But if you need more, result map can still satisfy you *** to the limit.

The columnIndex attribute provides a way for us to map the subscript field of the dataset to the specified data object attribute, but this method should be used as little as possible, and you will find that this will have a large side effect on our future maintenance and readability.

The dbType attribute clearly indicates the type of database this field corresponds to, which I rarely use in most cases.

The type attribute explicitly indicates the data type of the data object attribute to which this field will correspond. Usually, setting this attribute is necessary if you want to ensure type safety.

◆ The resultMapping attribute is slightly more complex. It is used in a scenario. If the attribute of a data class itself is not a primitive data type, but a complex data type, then we cannot simply give it a simple result element. We must also give it a complete resultMap. The resultMapping attribute exists to accomplish this function. Its attribute value is the ID of an existing resultMap.

The nullValue property is not worth mentioning, it gives the default value of this field when its value is null.

◆select attribute is as complex as resultMapping. First of all, its attribute value must be the ID of a query statement that returns a data set. The data class attribute that can configure this attribute can be a primitive type, a composite type, or a collection type that includes multiple pieces of data. These types are all OK and there is no problem. One of its important existence significance lies in describing the relationship between different tables. Through this query, you can use the select attribute when you want to query related fields from another table without joining. As follows:

﹤resultMaps﹥ ﹤resultMap id="DemoResultMap" class="Hashtable"﹥ ﹤result property="id" column="id"/﹥ ﹤result property="Children" column="id" select="SELECT_Children"/﹥ ﹤/resultMap﹥ ﹤/resultMaps﹥ ﹤statements﹥ ﹤select id="SELECT_Children" resultClass="ChildrenObject"﹥ SELECT * FROM Children WHERE ParentID = #id# ﹤/select﹥ ﹤/statements﹥

In this way, it is possible to express the relationship between different tables and the data reading problem without programming. But there's a possibility that if you read data every time, you'll find that you interact with the database more often, and even if you don't need the data every time, won't that be a waste of data reads? The lazyLoad attribute next provides us with a solution to the second problem, that is, delayed loading of data, yes, delayed loading can greatly improve the performance of data access, it only needs to read the data, for the master-slave table relationship, this way may be the *** solution.

OK, so much for ResultMap. Next, I want to record some of the problems I encountered in using it:

I. When using ResultMap, you should be careful that if you give a configuration field in ResultMap, but you do not return this field when you return the dataset, the program will throw an exception. But conversely, if you return fields that are not configured in ResultMap, those fields will not be processed and will not give you any hint, rather than being queried. You should pay special attention to this problem.

II. If there is no special requirement, I suggest that the attributes of the data class be designed to compare with the database field words, so that if we do not have to write the ResultMap in general, in fact, if there is no such special requirement, writing the ResultMap is still a very time-consuming and error-prone task.

III. When using lazyLoad, pay special attention to that not all types of data can be lazyLoad, only the type of IList interface implemented, and the attribute of the data class defined as IList type can be lazyLoad. (The question of whether only properties of type IList can be lazyLoad remains to be discussed, since in my experience only this type can be used, and even the Generic version of IList does not support it.) And when you use it, you can't convert this IList property to your real data type. Because at runtime, this property is wrapped as a dynamic type, this dynamic type still implements the IList interface, and it is because of this dynamic type that we can extend the functionality of lazyLoad. At this point the program is using runtime dynamic typing so you can't do strong typing.

The above is how to analyze the basics of iBATIS ResultMap. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserves, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.