L'analyse de principe des trois premiers Mybatis peut être consultée en cliquant sur le lien:
Analyse du principe Mybatis (deux) le processus de création de SqlSession
Cet article parle principalement du processus de requête de Mybatis basé sur les trois premiers articles (comme l'ajout, la suppression et la modification), et c'est aussi la connaissance de base de Mybatis. Je ne dirai pas grand-chose, mais le débogage est respectueux.
Nous avons dit dans le troisième article que l'objet d'interface Mapper que nous obtenons est en fait une classe d'implémentation proxy, le proxy est l'objet MapperProxy et l'objet MapperProxy n'implémente pas notre interface Mapper, donc lorsque nous appelons la méthode d'interface de la classe proxy , La méthode invoke donnera une condition pour juger s'il s'agit d'une méthode de la classe Object (s'il n'y a pas de tel jugement ici, le programme rapportera une erreur, voir l'explication au chapitre 3 pour plus de détails), il est évident que nous appelons la méthode d'interface, pas la méthode Object , Donc notre programme vient directement à la méthode cachedMapperMethod, en profondeur cette méthode
Voici en fait une optimisation, via un conteneur de carte pour mettre en cache notre MapperMethed, la clé est la méthode d'interface appelée Method, et la valeur est MapperMethod. Il existe deux attributs principaux dans cette méthode Mapper:
Un des objets SqlCommand, puis regardons ce qu'il y a dans ce SqlCommand et arrivons à son constructeur
Tout d'abord, c'est une classe interne de MapperMethod. Il y a deux attributs dedans, à savoir le nom et le type. Ensuite, je vais vous dire la fonction de ces deux attributs directement. L'attribut name obtient ce que nous appelons selon l'interface et la méthode passées. Le nom de chemin complet de la méthode va à Configuration pour obtenir le MappedStatement correspondant, puis attribue l'ID de l'objet MappedStatement au nom, et le type est le même, ce qui est également obtenu en affectant le sqlCommandType de MappedStatement. L'autre MethodSignature est aussi une classe interne de MapperMethod. Sa fonction est de déterminer quel type de méthode d'interface l'appel est retourné. Je n'en parlerai pas ici.
Les deux classes mentionnées ci-dessus jettent en fait les bases de ce qui suit, nous cliquons sur Suivant, arrivons à la méthode mapperMethod.execute et continuons en profondeur.
On peut voir que la première chose ici est de juger le type de méthode par le type de SqlCommand dans MapperMethod. Puisque nous sommes une méthode de requête ici, nous sommes arrivés à la branche SELECT.
Dans la branche SELECT, la valeur de retour de la méthode est à nouveau jugée, et différente si les branches sont prises en fonction de la valeur de retour de la méthode. Évidemment, le jugement conditionnel est ici le crédit de la MethodSignature que nous avons mentionné ci-dessus. Vient ensuite la méthode sqlSession.selectOne, transmise le nom de chemin complet de la méthode et les paramètres de la méthode d'interface à appeler, et continue à plonger.
Plongez dans la méthode selectList.
Aller plus loin.
On peut voir que selon la valeur de nom du sqlCommond précédent, l'objet MappedStatement correspondant est obtenu dans l'objet Configuration, puis la méthode executor.query est appelée. Notez qu'il existe une méthode wrapCollection. À partir du nom, nous pouvons voir qu'il doit être encapsulé pour notre objet paramètre. Pas grand chose ici. Continuez ensuite à plonger dans la méthode de requête.
L'objet BoundSql peut être obtenu via la méthode getBoundSql du MappedStatement entrant, qui contient notre instruction SQL d'origine. Et CacheKey est une valeur clé utilisée pour notre cache secondaire, continuez à plonger dans la méthode de requête ci-dessous.
La méthode de requête de CachingExecutor est appelée ici, car nous avons configuré le cache de deuxième niveau par défaut, donc l'Executor que nous exécutons réellement sera encapsulé par CachingExcutor. Nous en parlons ici dans la deuxième partie, nous n'entrerons donc pas dans les détails. Ensuite, s'il n'y a pas de données dans notre cache secondaire, nous devons appeler notre véritable exécuteur. Allez en profondeur dans la méthode delegate.query.
Ceci est similaire au cache de deuxième niveau, il est d'abord extrait du cache local, c'est-à-dire du cache de premier niveau, nous pouvons donc savoir ici que l'ordre des sources de données dans Mybatis est d'abord le cache de deuxième niveau, puis le cache de premier niveau et enfin la base de données. Nous plongeons dans la méthode queryFromDataBase.
Méthode doQuery approfondie
À ce moment, je suis arrivé à la méthode doQuery de SimpleExecutor. J'ai vu que j'avais d'abord obtenu l'objet Configuration de l'objet MappedStatement entrant, puis j'ai appelé la méthode newStatementHandler de la configuration. Cette méthode a renvoyé un objet StatementHandler et a approfondi cette méthode.
Vous pouvez voir qu'un objet RoutingStatemnetHandler a d'abord été créé via la sous-classe. Qu'est-ce que cet objet RoutingStatemnetHandler? Jetons un coup d'œil à sa méthode de construction.
Dans ses propriétés, il y a un objet de propriété StatementHandler. En fait, cet objet de propriété est le véritable objet d'exécution de la méthode de cette classe. Autrement dit, le RoutingStatementHandler est en fait une couche d'empaquetage et la création de cet objet est basée sur notre fichier de configuration Pour déterminer le statementType défini dans, la valeur par défaut consiste à créer un PrepareStatementHandler précompilé.
Ensuite, regardez le code interceptorChain.pluginAll (statementHandler) dans la case rouge ci-dessus . C'est un code très familier. En fait, ce code est apparu lorsque nous avons initialisé l'Executor. Nous verrons également ce code dans le code suivant. Lié au mécanisme de plugin de Mybatis. Alors, quel est cet objet StatementHandler? Exécutons d'abord le code suivant.
Après avoir exécuté la méthode newStatementHandler, je suis arrivé à la méthode prepareStatement ci-dessous pour approfondir cette méthode.
On peut voir qu'en fait, notre objet StatementHandler est utilisé pour obtenir l'objet Statement, et cet objet Statement est l'objet Statement dans le jdk lorsque nous apprenons la programmation JDBC, donc le fonctionnement de la base de données par Mybatis encapsule réellement JDBC. Voyons comment le StatementHandler obtient l'instruction, et allons dans handler.prepare
Vous pouvez voir que la méthode prepare de prepareStatement est appelée et que cette méthode est utilisée en profondeur.
Vous pouvez voir ici que vous obtenez l'instruction sql de boundSql, puis que vous appelez la méthode connection.prepareStatement pour passer le sql, de sorte que vous obtenez l'objet Statement.
Puis est venu handler.parameterize (stmt), puis nous sommes entrés et avons jeté un coup d'œil.
La méthode setParameters de parameterHandler est appelée à l'intérieur, et quel est cet objet parameterHandler? Revenons à l'initialisation du PreparedStatementHandler avant.
Un tel objet parameterHandler n'existe pas dans PreparedStatementHandler et PreparedStatementHandler est hérité de BaseStatementHandler, de sorte que l'objet d'initialisation parameterHandler doit être dans la méthode de construction de sa classe parent BaseStatementHandler.
Venez à la méthode de construction de BaseStatementHandler, approfondissez la méthode configuration.newParameterHandler.
On peut voir que newParameterHandler et newResultSetHandler ont un mécanisme pour appeler le plug-in Mybatis. À l'heure actuelle, nous savons que les quatre objets qui peuvent être interceptés par le plug-in Mybatis sont Executor, StatementHandler, ParameterHandler et ResultSetHandler . En fait , ces quatre objets peuvent être interceptés par le plug-in Mybatis. Dans Mybatis, nous avons l'habitude d'appeler ce Mybatis Quatre composants majeurs.