Análisis del principio de Mybatis (tres) -getMapper obtiene dinámicamente la clase de implementación de la interfaz

En el artículo anterior, describimos cómo crear SqlSession en Mybatis, sabiendo que en el proceso de creación de SqlSession, la capa inferior de Mybatis en realidad nos está ayudando a crear el ejecutor Executor, y se almacena en la DefaultSqlSession creada. Los amigos que conocen el proceso de creación de DefaultSqlSession pueden ir a

Análisis del principio de Mybatis (dos) el proceso de creación de SqlSession

Volviendo al tema de este artículo, después de obtener DefaultSqlSession con Executor, necesitamos obtener nuestra clase de implementación de interfaz correspondiente a través de esta DefaultSqlSession para getMapper. Generalmente llamado así

UserMapper userMapper = sqlSession.getMapper(UserMapper.class);

Entonces, en este momento, depuramos y vemos qué sucedió en la parte inferior.

Después de ingresar, el método getMapper del objeto Configuration de DefaultSqlSession se llama en el interior, pasando el tipo de objeto de clase y él mismo como parámetros, y continuando profundizando.

 En el método de configuración getMapper, el método getMapper de MapperRegistry se llama adentro. Este objeto MapperRegistry es familiar. ¿Dónde has visto a Ni? De hecho, este objeto apareció en el proceso de creación de SqlSessionFactory en nuestro primer artículo, cuando se inicializó el objeto Configuration subyacente, por lo que ahora podemos saber que hay un objeto de propiedad Mappers Map conocido en este objeto. Este mapa se almacena en nuestro El objeto de clase de interfaz es la clave y MapperProxyFactory correspondiente al objeto de clase de interfaz es el valor. Ahora ve más profundo.

Puede ver que knownMappers obtiene el objeto MapperProxyFactory correspondiente de acuerdo con el objeto Class de interfaz que pasamos. Luego continuamos ejecutando el método mapperProxyFactory.newInstance (sqlSession) Obviamente, este método eventualmente devuelve un objeto genérico a la capa superior, por lo que este método es el foco. Ve más profundo.

En el interior, un objeto MapperProxy es nuevo y luego se pasa al método newInstance como parámetro, entonces, ¿qué es este MapperProxy? Entremos y echemos un vistazo.

 Se puede encontrar que el modo proxy dinámico de jdk se usa aquí. Mira su método de invocación.

 Luego, en este momento, primero regresamos al método newInstance de mapperProxyFactory.

 

Finalmente, el objeto de proxy dinámico obtenido se devuelve a la capa superior.

Una cosa más aquí, de hecho, la clase MapperProxy es solo un trampolín para crear nuestra clase proxy dinámica, lo que queremos es usarla para crear nuestra clase proxy, y esta clase proxy no es responsable de los métodos de la clase MapperProxy. Cualquier mejora. Debido a que usualmente usamos un proxy dinámico para mejorar la lógica antes y después de algunos métodos de la clase de destino de un determinado proxy, este no es el caso aquí, solo se usa la clase de proxy, por lo que no nos importa el método de invocación. La lógica del método de invocación está relacionada con la lógica inferior del método de invocación. Todas nuestras operaciones de adición, eliminación, modificación y verificación posteriores se aplican a la siguiente lógica.

Supongo que te gusta

Origin blog.csdn.net/weixin_37689658/article/details/99083083
Recomendado
Clasificación