MyBatis know how much (2)

MyBatis has absorbed a large number of outstanding features and ideas from the most popular relational database access methods, and identified synergies. Demonstrates how the MyBatis framework absorbs the knowledge we have learned over the years in the development of database integration in different ways, and combines the best ideas to form this hybrid solution.

The following sections discuss these different database access methods, and ibatis the good ideas that are drawn from each approach.

Sql

The core of MyBatis is SQL. Fundamentally, all relational databases support SQL and use it as the primary way to interact with the database. SQL is a simple, non-procedural language for manipulating databases, in fact, SQL contains two languages.

The first is the data definition language (Language, DDL), which contains statements such as create, drop, and alter. These statements are used to define database data and its design, including tables (table), Columns (column), index (index), Constraints (constraint), procedures (procedure), and foreign key relationships (foreign key relationship). IBATIS does not directly support DDL. Although many people did successfully execute the DDL through Ibatis, we do not recommend this because the DDL should normally be owned and controlled by a database management team, and the application developer has no right to manipulate it.

The second language that SQL contains is the data manipulation statement (manipulation LANGUAGE,DML). DML Package

Statements such as SELECT, INSERT, update, and delete are used to manipulate data directly. Initially, SQL was designed as a language that was simple enough for the end user to use. According to this design idea, the image user interface is completely unnecessary, and even the application is not required. This, of course, goes back to the time when it was always a "flashing cursor on a black screen", in which time we could expect more from end users.

The database has become too complex to expect the end user to manipulate the database directly through SQL. Can you imagine a situation like this: handing over a bunch of SQL statements to the Accounting department, and then saying, "That's it, look for the Bsheet table and you'll find the information you need." "This is simply impossible.

Just because SQL itself is no longer an effective interface for end users, SQL is still a very powerful tool for developers. SQL is the only way to have complete access to the database, and all other tools are just a subset of the full functionality. For this reason, MyBatis fully supports SQL and takes it as the primary way to access relational databases. At the same time, MyBatis also has the advantages of many other methods, including stored procedures and object/relational mapping tools.

1. Legacy Stored Procedures

Stored procedures (stored procedure) may be considered the oldest way to write applications for relational databases. Many legacy systems use what we now call the "two-tier (Two-tier)" Design. The two-tier design includes a rich client interface to directly invoke stored procedures in the database. These stored procedures may contain SQL that can be used to manipulate the current database. In addition to SQL, these stored procedures may also contain (and often do contain) business logic. Unlike SQL, the language used to write these stored procedures is procedural, with process control statements such as conditional statements and iteration statements. In fact, you can create a complete application just by using a stored procedure. Many software developers have also developed rich client tools such as Oracle Forms, PowerBuilder, and Visual Basic to support the development of "two-tier" database applications.

The biggest problem with the two-tier application is its performance and extensibility. Although the capabilities of the database are indeed very powerful, they are often not necessarily the best choice for dealing with hundreds or even millions of user visits. For modern web applications, the need for extensibility is not uncommon. The limitations of the database in terms of concurrency, hardware resources, and network sockets will make this "two-tier" architecture vulnerable to failure when it needs to scale up. In addition, the deployment of a "two-tier application" is a nightmare. In addition to the usual rich client deployment issues, the complex runtime database engine needs to be deployed to the client machine.

2. Modern stored procedures

In some circles, stored procedures are still considered best practices for three-tier (Three-tier) and eight-tier (n-tier) applications, such as Web applications. But now stored procedures are often treated as remote procedure calls from the middle (middle tier) (procedure call, RPC), and many performance constraints can be addressed by establishing indirect pools and database resource management. In modern object-oriented applications, stored procedures are still an effective design choice for implementing a complete data access layer. Stored procedures do have an advantage in terms of performance because they are always able to complete data operations in the database faster than any other solution. However, there are more issues to pay attention to than performance.

Putting business logic in a stored procedure is often considered a bad design. The main reason is that the development of stored procedures is difficult to conform to the architecture of modern applications. They are difficult to write, difficult to test, and difficult to deploy. Worse, modern enterprise databases are typically owned by other database management teams and protected by the most stringent change controls. They are often not rapidly changing to suit the needs of modern software development methodologies. In addition, there are some limitations to using stored procedures to implement complete business logic. If the business logic requires access to other systems, resources, or user interfaces, the stored procedure will probably not be able to handle all of these logic. Modern applications are complex and require a more general language, rather than a dedicated language that optimizes data manipulation capabilities just like stored procedures. To solve this problem, some developers have embedded a more powerful language like Java in their database engine to write stronger stored procedures. But that doesn't really solve the problem, it only makes the boundaries of the application and the database more blurred and creates a new burden for the database administrators: They now need to start worrying about Java and C # in the database. This is really the wrong tool to solve the problem.

One of the most frequently seen scenarios in software development is overkill (overcorrection). When a problem is discovered, the first solution that is tried is often the exact opposite approach. Instead of solving the problem, the result is often the introduction of an equal amount of completely different new problems. For example, we will discuss inline SQL below.

Series Articles:

MyBatis know how much (1)

MyBatis know how much (2)