Shulou(Shulou.com)06/02 Report--

How to analyze the application of iBATIS interface, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

The origin of iBATIS interface application, with the promotion of Java 5, we have the opportunity to improve the user experience. The most important of these is that with Java 5, you can eliminate confusing type conversions and character-based invocations of SQL mapping. For example, it now looks like this when calling the SQL map:

Employee employee = (Employee) sqlMapper.queryForList ("getEmployee", 5); / /... and... List employees = sqlMapper.queryForList ("listAllEmployees")

The problem is obvious. * the names of the mapped statements in the above two examples are based on strings, which can easily lead to errors. This approach will not be supported and managed by IDE tools and compilers.

The second problem is the type safety of parameters and return values. In the * * example, who can guarantee that the parameter must be of type Integer? And who can guarantee that the return value you get will be of type Employee? Here, the compiler will not give any compensation error reports and prompts. Only run-time exceptions are thrown.

* the problem is the same in the example of the collection. Before running, you may get a collection of Dogs instead of Employees.

In short, although this approach is better than JDBC, it also makes people feel uncomfortable, and there is still room for improvement.

The iBATIS interface is used in Java 5. We can make full use of paradigms to standardize collection types. In this way, we can establish a consistent API for collection types without special configuration. Instead of declaring types in XML files or invoking mapped statements through character names, we can make full use of well-expressed and type-safe interface types. There is nothing new to learn, just a common interface.

Public interface EmployeeMapper {Employee getEmployee (int employeeId); List listAllEmployees ();}

That's enough! IBATIS to help us implement this interface.

Now we can call the mapped statement in a more concise and secure way.

Employee emp = empMapper.getEmployee (5); / /... and... List employees = empMapper.listAllEmployees ()

In the above call, there is no type conversion, no string, and the type of the parameter and return value is safe. The extra code is configured for the interface using the identity of XML or Java. At most, we only need to configure SQL statements, parameters that need to be overloaded, or return value types.

The interface describes everything you need.

The name of the statement (by default, it matches the name of the method)

Parameter type (if any)

Returns the value type (including the type of the element of the paradigm collection)

The most interesting of these is that we can generate SQL mappings based on conventions such as method names. These details will be discussed in more detail in future chapters on configuration.

The method bound by the iBATIS interface makes it easy for a framework such as Spring to inject mapped classes into other classes without exposing too many details of transaction management.

So much for the answers to the questions on how to apply the iBATIS interface. I hope the above content can be of some help to you. If you still have a lot of doubts to solve, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.