MyBatis Getting Started-mapper agent principle

Original DAO layer Development

After we have developed the first small program with MyBatis, I believe we have a general idea about the development of DAO layer. The other configuration does not change, the original test method, the DAO method, the original return value, directly in the DAO layer to receive it. is still the same old, first big frame, then write the configuration file and Usermapper.xml file this series of operations. If you do not understand, please refer to my blog "Getting Started the first program."

All we need to do is establish a session factory (Sqlsessionfactory) and then use session factory to create the session (Sqlsession). It then gets the SQL statement by reading the configuration file, executes, and then returns the data to the DAO layer object. The operation is as follows

First, create a DAO layer interface on the original basis.

　　　　

Then write an implementation class for the DAO layer interface

1  Public classUserdaoimplImplementsUserdao {2  3 //need to inject sqlsessionfactory into the DAO implementation class4 //this is injected through the construction method5 Privatesqlsessionfactory sqlsessionfactory;6  7  PublicUserdaoimpl (sqlsessionfactory sqlsessionfactory) {8  This. Sqlsessionfactory =sqlsessionfactory;9 }Ten   One @Override A  PublicUser Finduserbyid (intIdthrowsException { -Sqlsession sqlsession =sqlsessionfactory.opensession (); -   theUser user = Sqlsession.selectone ("Test.finduserbyid", id); -   - //Freeing Resources - sqlsession.close (); +   - returnuser; +   A } at   - @Override -  Public voidInsertuser (user user)throwsException { -Sqlsession sqlsession =sqlsessionfactory.opensession (); -   - //Perform an insert operation inSqlsession.insert ("Test.insertuser", user); -   to //Commit a transaction + sqlsession.commit (); -   the //Freeing Resources * sqlsession.close (); $  Panax Notoginseng } -   the @Override +  Public voidDeleteUser (intIdthrowsException { ASqlsession sqlsession =sqlsessionfactory.opensession (); the   + //Perform an insert operation -Sqlsession.delete ("Test.deleteuser", id); $   $ //Commit a transaction - sqlsession.commit (); -   the //Freeing Resources - sqlsession.close ();Wuyi   the } -   Wu}

And then we're testing the code we wrote.

There are some problems with this development:

There is a lot of duplicate code in the implementation class of the 1.dao interface, which increases the programmer's workload.

2. In the implementation class, the Sqlsession method hard-encodes the statement ID (where "Test.finduserbyid" is the ID of statment) when invoking the SQL statement in the map file.

　　　　

3. The variable passed in when the Sqlsession method is called, because the Sqlsession method uses generics, even if the variable type is not passed in to the parameter type in the DAO method, it does not error when compiling, and is not conducive to the development of the program.

　　　　

To solve these problems, we omit the development of the entity layer's implementation class by satisfying some specifications, and the proxy implementation class provided by the MyBatis framework gives us a dynamic call to our mapping file and then executes the methods in the class.

The principle of Mapper proxy method

Before you do this, declare that when you use the Mapper proxy, the naming is not the same as before. Here the interface name from the original * * changed to **mapper, for example, the original user interface, is now changed to Usermapper. Its content and nature have not changed, just changed a naming convention. In addition to the interface map file is changed from User.xml to usermapper.xml its contents unchanged.

The idea of the Mapper proxy method is that the programmer then writes the interface to the persistence layer.

　　　　

and corresponding configuration files for each interface.

　　　　

In our original method we need to write an implementation class for the interface, which is used to build the session factory (Sqlsessionfactory) and the corresponding session (sqlsession) and then read the SQL statements in the mapping file through the session (not accurate here, but so to understand). Then I can do some articles on this entity class:

1. We can create a proxy class that is created by the proxy class when our corresponding interface is called, and it is not difficult to create session factories and sessions.

2. There is the method name that our Sqlsession object invokes, which is well understood and corresponds to the label of our mapping file.

3. The next step is to pass in the parameter and receive the return value of the question:

3.1 Incoming parameters: we need to pass in a total of two parameters, one is the statement ID of the mapping file string, and the other is to execute the required parameters. The problem with this string generation is that it is more difficult. Each of our methods exactly corresponds to the ID of which mapping file is statement. For this problem, MyBatis gives us a workaround: The string that our entity-level object reads is this:test.insertuser

　　　　This ID can be divided into two parts, in which test is the value of the namespace in our mapping file, which matches the address of the persistent layer interface so that the proxy object can dynamically generate the first half of the ID through the address of the interface, which is part of the test The second half is consistent with the method of statement ID and interface in the mapping file.

In other words, when a user invokes a method of an interface, MyBatis can generate an incoming string of Sqlsession objects based on the interface address and the corresponding method name. This solves the problem of passing in the string in the parameter.

There is a second question: our incoming specific parameters, MyBatis, the incoming parameter type must be the same as the incoming parameter type of the interface. In this way, our incoming parameter type is done.

3.2 When the incoming parameter is done, the return value is done, as with the parameters passed in, the type requirement of the return value is the same as the interface return value, so that the return value can be passed out in the proxy class.

With this in place, we can use the proxy object instead of our physical layer to implement the class specifically.

At this point, these problems are almost all solved, but there is another problem: Our Select method return value problem, the proxy object is to use the Selectont method to query the database or use the SelectList method? This is related to the return value type of our interface (Mapper)--If the Mapper method returns a single Pojo object (not a collection object), the proxy object queries the database internally through SelectOne, and if the Mapper method returns a collection object, The proxy object queries the database internally through SelectList.

Mapper Proxy method

The principle is finished, the use actually basically did not have anything to say.

First we will create an interface.

　　　　

Then write the corresponding interface of the XML file (intercept part, namespace is not at).

Finally, don't forget to load usermapper.xml in the Sqlmapconfig.xml file.

　　　　

Test, it is necessary to say that our proxy object is obtained by Sqlsession.getmapper (interface bytecode file). ：

　　　　

At this point, the entity layer implementation Class of our MyBatis entity layer can be omitted from writing. However, the disadvantage of this is to enhance the coupling of the code, each interface and each mapping file must correspond. However, it is still felt that by complying with certain specifications, the amount of code is greatly reduced and more cool.

MyBatis Getting Started-mapper agent principle