iBATIS best practices in Java

Encoding PDF 417 in Java iBATIS best practices

The most common question with regard to mapping file organization is what to organize them by. Should you organize them by database table How about by class Perhaps organize them by the type of statement The answer depends on your environment. Although there is no right answer, don t get too fancy about it. iBATIS is very flexible, and you can always move the statements around later. As a starting point, it s best to organize your maps by the type that the statements return and the types they take as a parameter. This generally creates a nice organization of maps that you can navigate based on what you re looking for. So for example, in a Person.xml mapping file, you should expect to find mapped statements that return Person objects (or collections of Person objects), as well as statements that take a Person object as a parameter (like insertPerson or updatePerson).

There can be a lot of things to name in iBATIS: statements, result maps, parameter maps, SQL maps, and XML files all need names. Therefore, it s a good idea to have some sort of convention. We ll discuss one convention here, but feel free to use your own. As long as you re consistent within your application, you won t have any trouble.

Statements should generally follow the same naming convention as methods in the language in which you re programming. That is, in a Java application, use statement names like loadPerson or getPerson. In C#, use statement names like SavePerson or UpdatePerson. Using this convention will help you maintain consistency, but it also will help with method-binding features and code-generation tools.

Most of the time parameter maps will not have to be named, because inline parameter maps are much more common than explicitly defined ones. Due to the nature of SQL statements, parameter maps have limited reusability. You generally can t use the same one for both an INSERT statement and an UPDATE statement. For this reason, if you do use an explicitly defined parameter map, we recommend adding the suffix Param to the name of the statement that uses it. For example:

Result maps are bound to a single class type and the reusability of result maps is quite high. For this reason, we recommend naming result maps using the type they are bound against; also, append Result to the name. For example:

There are two kinds of XML files in iBATIS. The first is the master configuration file and the others are the SQL mapping files. The master configuration file The master configuration file can be called whatever you like; however, we recommend calling it SqlMapConfig.xml. If you have multiple configuration files for different parts of the application, then prefix the configuration filename with the name of the application module. So if your application has a web client and a GUI client with different configurations, you might use WebSqlMapConfig.xml and GuiSqlMapConfig.xml. You may also have multiple environments in which you deploy, such as production and test environments. In this case, prefix the filename with the type of environment as well. Continuing with the previous example, you might have ProductionWebSqlMapConfig.xml and TestWebSqlMapConfig.xml. These names are descriptive, and the consistency creates opportunities to automate builds to different environments. The SQL mapping files How you name the SQL mapping files will depend a lot on how you ve organized your mapped statements. Earlier in this book we recommended that you organize your mapped statements into separate XML files based on their return types and parameters. If you ve done that, naming the file after the return types and parameters will also work. For example, if one mapping XML file contains SQL statements involving the Person class, then naming the mapping file Person.xml would be appropriate. Most applications will do fine with this naming approach. There are other considerations, though. Some applications may require multiple implementations of the same statement to match different databases. For the most part, SQL can be written in a portable way. For example, the original JPetStore application that was written with iBATIS was compatible with 11 different databases. However, sometimes there are features of the database that are not portable but that are ideal for the solution being implemented. In cases like this, it becomes acceptable and even important