Implementing Castor data binding, Part 4: Binding Java objects to SQL data

This article supporting source code

For most developers-especially the various Java versions of users-data binding has become part of a common vocabulary like closures, single cases (singletons), Ajax. And as with other terms, data binding is often incorrectly defined.

In particular, most programmers are actually thinking about XML data binding when they hear data binding. Adding this little word XML has caused most programmers to overlook quite a bit of functionality and flexibility, especially if the Castor API is used. This is because XML data binding is just one part of Castor. In addition to binding to XML documents, Castor provides the ability to bind Java data to a SQL database. This is known as SQL data binding.

Defining SQL Data Binding

SQL data binding may be a new term, and the concept is actually very simple. In fact, it's best to look at it from a more familiar term XML data binding. XML data binding is the process of establishing a mapping between XML document data-typically stored in elements and attributes-and the properties of the Java object model. You can move data between the two by marshalling the program Reconciliation Group program. The marshalling program obtains data from the Java object Model and stores it in an XML document, and the solution Group program obtains the data from the XML document into the properties of the Java object model.

On this basis, we say that SQL data binding is not surprising in that SQL database data-stored in schemas, tables, columns, and so on-is mapped between Java objects. The same process of grouping and reconciliation, except that the conversion is between Java objects and SQL rather than XML. In fact, if you replace XML with SQL in most data-binding articles and change the element data to table records, the discussion becomes SQL data binding.

The meaning of SQL data binding

Java Technology was just born as a toy language, largely because its APIs were simple and focused on images (remember AWT?). ）。 The hallmark of Java technology's maturing is the Java database Connection (JDBC), which can be persisted to the SQL database. The only problem with JDBC in the past (and now) is that it is cumbersome to use. Not that it's more complicated, but that it adds too much extra work to most programs.

Using Castor and SQL data binding can avoid most of the complexity. Even better, this API is essentially the same for XML and SQL context functionality. And with data binding, there is less detail that the application needs to care about. Dealing with JDBC ResultSet and the number of rows is no longer your code problem, several simple marshalling group calls can handle transformations between Java objects and SQL databases.

Perhaps the most interesting thing about SQL data binding is that it is not under too much pressure and attention. In particular, given the large number of programmers who are wary of XML, say it is tedious, or they prefer to use binary serialization. But these people welcome the hands of SQL. In fact, you might be surprised to find that a large number of programmers and even real programmers don't think that SQL is a legitimate data storage and persistence technology (see how many people around you think relational databases are unwieldy, exaggerated, or outdated).

That being the case, SQL data binding is no doubt more meaningful than its XML brother. It is necessary to persist (or store) data in an enterprise application, and writing data access and retrieval code is painful. SQL data binding uses a familiar API (assuming you've read the previous article in this series) for SQL data storage. A few lines of command can write data to a table (or multiple tables) or read it.

is still mapped

A particularly important point of SQL data binding is the ability to establish a mapping of Java objects to SQL data schemas without the need to bind Java or SQL names. Compared to XML, the structure of relational databases is often far from the structure of Java objects. A table is a collection of data, and an object typically represents a part (possibly a row) of data. Relationships between objects must be tracked to other objects, just as relationships between tables are tracked to other tables. However, there are no one-to-many connection tables in the Java object model, and of course there are no many-to-many connections.

Even in a moderately complex relational database, things are designed differently from the object model. The mapping between SQL and Java objects, a lot of work is to define the mapping between objects and tables. Although mappings can be complex, several simple mappings are used in this article to illustrate the rationale for mappings in SQL data binding.

This is JDO, right?

Is. But it's not all right. That's a bit right. It's a little confusing here.

Sun has a specification called the Java data Object (Java objects,jdo). Java specification Request (JSR) (JDO 1.0) and JSR 243 (JDO 2.0) define a very specific method of SQL data binding (although never explicitly referred to as "SQL data Binding"). If you read JDO and then read the introductory section of this article, you'll find that it's one thing. However, Castor's JDO (yes, Castor, also known as JDO, is more chaotic) differs from Sun jdo, even without any relationship, except that the basic goals are the same.

Given the potential for a lot of confusion, again: If you use Castor JDO, then it's not Sun's standard API. But the problem is not as bad or straightforward as it seems. In fact, Castor developers are trying to incorporate many of their API features into the Sun data binding and JDO APIs. So while Castor is not yet a standard API, many features-including the API itself-may one day become a standardized JDO API.