MyBatis as a popular semi-automatic ORM framework, which integrates many excellent design concepts, analysis of its source skeleton can help you establish a good project design experience. Because of its complexity, I will break it down into several chapters. Let’s embark on the journey of conquest!

First import MyBatis source package into IDEA, and then create a project to rely on the local package, so we can debug calls.

Because unlike Tomcat, MyBatis relies on external calls to start.

The basic support layer of MyBatis is based on iBatis, which adds appearance mode on the basis of iBatis to facilitate the use of coders more intuitively.

So let’s take a look at its core package:

The beauty is that each module is poorly coupled and a package is a separate module. So when we analyze a single module, related classes are in the same package, is not very convenient.

The log module

MyBatis does not provide a Log implementation class, only provides a Log interface, specifying four levels of Trace, DEBUG, WARN, error:

public interface Log {

  boolean isDebugEnabled(a);

  boolean isTraceEnabled(a);

  void error(String s, Throwable e);

  void error(String s);

  void debug(String s);

  void trace(String s);

  void warn(String s);

}
Copy the code

MyBatis integrates the logging plugin with log4j:

Let’s open this Log4jImpl and see how it integrates the logging plug-in:

First, it implements the Log interface, and then hands Log handling off to a Logger object (the actual print class in Log4J), typical adapter pattern. The same is true for other logging plugins. Take a look at the class diagram for the Log module:

This is a factory pattern, and we can see the loading order of the logging plug-ins by looking at the factory code:

When a database operation is performed, the corresponding log is printed:

We don’t have a print statement in our code. Where is it called?

This is the excellence of MyBatis, which truly achieves the separation of business and technology.