Mapperfactorybean and Mapperscannerconfigurer
Spring Injection Mapper
Four ways to use MyBatis for data processing
①sqlsessiontemplate②sqlsessiondaosupport③mapperfactorybean④mapperscannerconfigurer
①sqlsessiontemplate: This needs to write the configuration file, inject sqlsession into the implementation class, and then use the sqlsession, which is fine particle control (non-interface development)
②sqlsessiondaosupport (in existing and older jar packages): This only needs to inherit special classes in the implementation class (for example, Hibernatedaosupport)
Can be developed using sqlsession (non-interface mode)
③mapperfactorybean: This to write the configuration file, the corresponding interface in the configuration file reference, no need to write implementation class, need to manually inject (dynamic agent development)
④mapperscannerconfigurer: This to write the configuration file, as long as the interface is located in the package, will automatically introduce the interface in the package,
No need to write implementation class, using annotation scanning method @autowired (dynamic proxy)
In Springmvc, you don't have to write a corresponding implementation for every DAO, and you can give SPRINGMVC to create it for you.
To replace code that manually uses Sqlsessiondaosupport or sqlsessiontemplate to write data Access Objects (DAO), Mybatis-spring provides a dynamic proxy implementation: Mapperfactorybean. This class allows you to inject the data mapper interface directly into your service layer bean. When using mappers, you can invoke them just as you would call your DAO, but you don't need to write any DAO implementation code, because mybatis-spring will create the proxy for you.
Mapperfactorybean
The data mapper interface can be added to Spring as follows:
The proxy class created by Mapperfactorybean implements the Usermapper interface and injects it into the application. Because the agent is created in the runtime environment (runtime, translator note), the specified mapper must be an interface, not a specific implementation class.
If the usermapper has a corresponding MyBatis XML mapper file, if the XML file is in the same location as the class path and the Mapper class (that is,. Java and the. XML file under the same package), it will be automatically solved by the Mapperfactorybean Analysis . It is not necessary to specify the mapper in the MyBatis configuration file unless the mapper's XML file is under a different classpath.
Note that when Mapperfactorybean requires Sqlsessionfactory or sqlsessiontemplate. These can be set by their respective sqlsessionfactory or Sqlsessiontemplate properties, or they can be assembled from Spring. If the two properties are set, then the sqlsessionfactory is ignored because sqlsessiontemplate is required to have a session factory setting; The factory will be used by Mapperfactorybean.
You can directly inject the mapper directly into the Business/service object in the same way that you inject any Spring bean:
This bean can be used directly in the application logic:
Note that there is no reference to sqlsession or MyBatis in this piece of code. There is no need to create, open or close the session of the Code, Mybatis-spring will come to care about it.
Mapperscannerconfigurer
It is not necessary to register all the mappers in the Spring XML configuration file. Instead, you can use a mapperscannerconfigurer, which will look for mappers under the classpath and automatically create them into Mapperfactorybean.
To create a mapperscannerconfigurer, you can add the following code to the Spring configuration:
The Basepackage property lets you set the basic package path for the Mapper interface file. You can use semicolons or commas as separators to set more than one
Path to a package. Each mapper will be recursively searched in the specified package path.
Summarize:
Mapperfactorybean needs one of the matching
Mapperscannerconfigurer can configure multiple
Spring and MyBatis Integration configuration Mapperfactorybean and Mapperscannerconfigurer differences