Principio APP
Transacción: La transacción es un modelo de componente indispensable en las aplicaciones informáticas, que garantiza la atomicidad, coherencia, aislamiento y persistencia de las operaciones del usuario.
Transacciones locales: Estrechamente dependiente del administrador de recursos subyacente, el procesamiento de transacciones se limita a los recursos de transacción actuales. Este método de procesamiento de transacciones no depende del servidor de aplicaciones, por lo que es flexible de implementar pero no puede admitir transacciones distribuidas de múltiples fuentes de datos.
Transacción distribuida: Java Transaction Programming Interface (JTA: Java Transaction API) y Java Transaction Service (JTS: Java Transaction Service) proporcionan servicios de transacciones distribuidas para la plataforma J2EE. La transacción distribuida (Transacción distribuida) incluye un administrador de transacciones (Administrador de transacciones) y uno o más administradores de recursos (Administrador de recursos) que admiten el protocolo XA. Podemos considerar al administrador de recursos como cualquier tipo de almacenamiento de datos persistente; el administrador de transacciones es responsable de la coordinación y control de todas las unidades participantes en la transacción.
caché MyBatis
Hay caché de primer nivel y caché de segundo nivel en MyBatis, y el caché de primer nivel está habilitado de forma predeterminada. El caché de primer nivel se refiere al caché en el nivel SqlSession. Cuando se consulta la misma declaración SQL en la misma SqlSession, la consulta después de la segunda vez no se consultará desde la base de datos, sino que se obtendrá directamente del caché. El caché de nivel puede almacenar en caché hasta 1024 SQL. El caché de segundo nivel se refiere al caché que puede cruzar SqlSession. Es un caché en el nivel del asignador. Diferentes sqlSessions pueden compartir el caché en el nivel del asignador.
Caché de nivel 1: caché local de HahsMap basado en PerpetualCache. Su alcance de almacenamiento es Sesión. Cuando la sesión se vacía o cierra, se borrarán todos los cachés. El caché de nivel 1 está habilitado de forma predeterminada.
El mecanismo del caché de segundo nivel es el mismo que el del caché de primer nivel. El valor predeterminado es usar almacenamiento PerpetualCache y HahsMap. La diferencia es que su alcance de almacenamiento es Mapper (espacio de nombres) y la fuente de almacenamiento se puede personalizar. , como Ehcache. El caché de segundo nivel no está habilitado de forma predeterminada. Para usar la clase de atributo de caché de segundo nivel, debe implementar la interfaz de serialización Serializeable (que se puede usar para guardar el estado del objeto), que se puede configurar en su mapeo. archivo.
Para el mecanismo de actualización de datos de caché, cuando un ámbito (sesión de caché de primer nivel/espacios de nombres de caché de nivel dos) realiza operaciones C/U/D, el caché en la selección bajo el alcance se borrará de forma predeterminada.
¿Qué es MyBatis?
MyBatis es un excelente marco de capa de persistencia, un marco semi-ORM (mapeo relacional de objetos), que admite SQL personalizado, procedimientos almacenados y mapeo avanzado. MyBatis evita casi todo el código JDBC y la configuración manual de parámetros y la obtención de conjuntos de resultados. MyBatis puede usar XML simple o anotaciones para configurar y mapear tipos nativos, interfaces y POJO de Java como registros en la base de datos.
¿Qué es ORM?
ORM, mapeo relacional de objetos, es una tecnología para resolver la relación de mapeo entre datos de bases de datos relacionales y objetos Java simples (POJO). En pocas palabras, ORM se describe mediante el uso de metadatos básicos entre objetos y bases de datos. Perseverar automáticamente los objetos del programa en la base de datos relacional.
¿Por qué MyBatis es una herramienta de mapeo ORM semiautomática? ¿Cuál es la diferencia entre este y completamente automático?
Hibernate es una herramienta de mapeo ORM completamente automática. Cuando se usa Hibernate para consultar objetos asociados u objetos de colección asociados, se puede obtener directamente de acuerdo con el modelo de relación de objetos, por lo que es completamente automático.
Cuando Mybatis consulta objetos asociados u objetos de colección asociados, necesita escribir SQL manualmente para completar, por lo que se denomina herramienta de mapeo ORM semiautomática.
¿MyBatis admite la carga diferida? Si es compatible, ¿cómo se implementa?
MyBatis solo admite la carga diferida de objetos de asociación y objetos de colección: la asociación se refiere a uno a uno y la colección se refiere a uno a muchos. En el archivo de configuración de MyBatis, puede configurar si desea habilitar la carga diferida lazyLoadingEnabled=true|false.
Su principio es usar CGLIB para crear un objeto proxy del objeto de destino. Cuando se llama al método de destino, ingresa al método interceptor, como llamar a a.getB ().getName (), y el método interceptor invoke () encuentra que a.getB() es Si el valor es nulo, enviará la consulta SQL previamente guardada asociada con el objeto B por separado, consultará B y luego llamará a.setB(b), por lo que el atributo del objeto b de a tiene un valor y luego completa una llamada al método.getB( ).getName(). Este es el principio básico de la carga diferida.
¿Problemas en el desarrollo tradicional de JDBC? ¿Cómo resuelve MyBatis estos problemas?
1. La creación y liberación frecuentes de objetos de conexión a la base de datos fácilmente causarán un desperdicio de recursos del sistema y afectarán el rendimiento del sistema. Este problema se puede resolver utilizando un grupo de conexiones. Pero usar jdbc requiere que usted mismo implemente el grupo de conexiones.
Solución: configure el grupo de conexiones de datos en mybatis-config.xml y utilice el grupo de conexiones para administrar las conexiones de la base de datos
2. Hay definiciones de declaraciones SQL, configuraciones de parámetros y procesamiento de conjuntos de resultados codificados. En el proyecto real, es más probable que la declaración SQL cambie. Una vez que hay un cambio, es necesario modificar el código Java y volver a compilar y volver a publicar el sistema. No es fácil de mantener.
Solución: separe la declaración Sql del código Java en el archivo XXXmapper.xml
3. Hay una codificación estricta al usar prepareStatement para pasar parámetros al símbolo de ocupación, porque las condiciones donde de la declaración SQL no son necesariamente, puede haber más o menos, y el código debe modificarse para modificar el SQL, y el El sistema no es fácil de mantener.
Solución: Mybatis asigna automáticamente objetos java a declaraciones SQL
4. Hay códigos duplicados en el procesamiento del conjunto de resultados, lo que dificulta el procesamiento. Sería más conveniente si se pudiera asignar a un objeto Java.
Solución: Mybatis asigna automáticamente los resultados de la ejecución de SQL a objetos Java
Ventajas y desventajas de Mybatis
ventaja
En comparación con las tecnologías tradicionales de acceso a bases de datos, ORM tiene las siguientes ventajas:
Basado en la programación de declaraciones SQL, es bastante flexible y no tendrá ningún impacto en el diseño existente del programa de aplicación o base de datos. SQL está escrito en XML, lo que desacopla sql del código del programa y facilita la administración unificada; se proporcionan etiquetas XML para Admite la escritura de sentencias SQL dinámicas y reutilizables.
En comparación con JDBC, reduce la cantidad de código en más del 50%, elimina una gran cantidad de códigos redundantes de JDBC y no requiere conexión de interruptor manual.
Muy buena compatibilidad con varias bases de datos (debido a que MyBatis usa JDBC para conectarse a la base de datos, todas las bases de datos que Mybatis admite siempre que JDBC sea compatible)
diferencia
Se puede integrar bien con Spring
defecto
La carga de trabajo de escribir declaraciones SQL es muy pesada, especialmente cuando hay muchos campos y muchas tablas asociadas, existen ciertos requisitos para que los desarrolladores escriban declaraciones SQL.
Las declaraciones SQL dependen de la base de datos, lo que resulta en una mala portabilidad de la base de datos y la base de datos no se puede reemplazar a voluntad.
¿Cuáles son los pasos de programación de MyBatis?
1. Crear SqlSessionFactory
2. Cree SqlSession a través de SqlSessionFactory
3. Realizar operaciones de base de datos a través de SqlSession
4. Llame a session.commit() para confirmar la transacción.
5. Llame a session.close() para cerrar la sesión.
¿Cuál es la arquitectura funcional de myBatis?
Dividimos la arquitectura funcional de Mybatis en tres capas:
Capa de interfaz API: la interfaz API se proporciona para uso externo y los desarrolladores utilizan estas API locales para manipular la base de datos. Una vez que la capa de interfaz recibe la solicitud de llamada, llamará a la capa de procesamiento de datos para completar el procesamiento de datos específico.
Capa de procesamiento de datos: responsable de la búsqueda de SQL específica, el análisis de SQL, la ejecución de SQL y el procesamiento de mapeo de resultados de ejecución, etc. Su objetivo principal es completar una operación de base de datos de acuerdo con la solicitud de llamada.
Capa de soporte básico: Responsable del soporte funcional más básico, incluida la administración de conexiones, la administración de transacciones, la carga de configuración y el procesamiento de caché, estas son cosas comunes y se extraen como los componentes más básicos. Proporcionar el soporte más básico para la capa superior de procesamiento de datos.
El ciclo de vida de Spring Bean.
El ciclo de vida de Spring Bean es simple y fácil de entender. Cuando se inicializa una instancia de bean, debe realizar una serie de operaciones de inicialización para lograr un estado utilizable. De manera similar, cuando ya no se llama a un bean, es necesario destruirlo y eliminarlo del contenedor del bean.
La fábrica de frijoles Spring es responsable de gestionar el ciclo de vida de los frijoles creados en el contenedor Spring.
Método de devolución de llamada llamado después de la inicialización.
Método de devolución de llamada llamado antes de la destrucción.
El marco Spring proporciona las siguientes cuatro formas de gestionar eventos del ciclo de vida de los beans:
Interfaz de devolución de llamada de InitializingBean y DesechableBean
Interfaces conscientes adicionales para comportamientos especiales
Método init() personalizado y método destroy() en el archivo de configuración de Bean
Métodos de anotación @PostConstruct y @PreDestory
Proceso de ejecución de Spring MVC
1. Spring MVC envía todas las solicitudes a DispatcherServlet y él confiará a otros módulos del sistema de aplicaciones que sean responsables del procesamiento real de las solicitudes.
2. DispatcherServlet consulta uno o más HandlerMappings para encontrar el controlador que maneja la solicitud.
3. DispatcherServlet envía la solicitud al controlador de destino
4. Después de que el Controlador realice el procesamiento de lógica de negocios, devolverá un ModelAndView
5. Dispatcher consulta uno o más solucionadores de vistas ViewResolver y encuentra el objeto de vista especificado por el objeto ModelAndView
6. El objeto de intento es responsable de renderizarlo y devolverlo al cliente.
¿Qué patrones de diseño se utilizan en el marco Spring?
Modo proxy: se utiliza más en AOP y comunicación remota
Modo singleton: los beans definidos en el archivo de configuración de Spring están predeterminados en modo singleton
Método de plantilla: utilizado para resolver el problema de la duplicación de código.
Controlador frontal: Spring proporciona DispatcherServlet para distribuir solicitudes
Intente ayudar (View Helper): Spring proporciona una serie de etiquetas JSP y macros de alta eficiencia para ayudar a integrar código disperso en la vista.
Inyección de dependencia: la idea central en toda la interfaz BeanFactory/ApplicationContext
Modo de fábrica: BeanFactory se utiliza para crear instancias de objetos.
¿Cómo garantiza el middleware de mensajes la coherencia de los mensajes?
1. La aplicación activa primero envía el mensaje al middleware de mensajes y el estado del mensaje se marca como pendiente.
2. Una vez que el middleware de mensajes recibe el mensaje, lo conserva en el almacenamiento de mensajes, pero no lo entrega a la aplicación pasiva.
3. El middleware de mensajes devuelve el resultado de la persistencia del mensaje (exitoso o no válido) y la aplicación activa juzga cómo manejar las operaciones comerciales en función del resultado devuelto;
1. Falla: abandone el procesamiento de la operación comercial y finalice (el resultado de la falla debe devolverse a la capa superior)
2. Éxito: ejecutar el procesamiento de operaciones comerciales
4. Una vez completada la operación comercial, envíe el resultado de la operación comercial (éxito/fracaso) al middleware de mensajes.
5. Una vez que el middleware de mensajes recibe el resultado de la operación comercial, lo procesa de acuerdo con el resultado.
1. Fallo: eliminar el mensaje en el almacenamiento de mensajes, finalizar
2. Éxito: actualice el estado del mensaje en el almacenamiento de mensajes que se enviará (se puede enviar) y luego realice la entrega del mensaje
6. Una vez que el proceso de reenvío anterior sea exitoso, envíe un mensaje a la aplicación pasiva.
