Data Access

I l @ ve RuBoard

Business applications inevitably need to use data. Most systems use a database of some sort , often a relational database. Applications can use SQL for querying and maintaining relational data.

SQL has a long and checkered history, which I won't relate. Suffice it to say that SQL is useful for identifying data and specifying operations to be performed in a standard manner, but that there are two things SQL does not do:

  • It does not specify how an SQL operation should be performed; it defines only what the results should be. This is not a problem for most developers (unless you're building your own DBMS). Database vendors fall over themselves trying to prove that their solution operates several orders of magnitude faster than the competition.

  • It does not define how SQL statements should be transmitted to the DBMS or how the DBMS should send back the results. As a result, database vendors use their own formats for transmitting data over the network, which in turn means that database clients end up locked into a particular vendor's DBMS. This can be a problem for the developer.

Open Database Connectivity

Microsoft has addressed the data transmission issue with Open Database Connectivity (ODBC). The ODBC architecture defines an extended SQL grammar and an API aimed at C programmers for submitting SQL requests to a data source. The ODBC architecture requires an ODBC driver for the target DBMS. The role of the driver is to act as an adapter that converts ODBC procedure calls and data into the format used by the underlying DBMS. Data returned by the DBMS passes back through the ODBC driver and is converted into a vendor-neutral format. The result is a decoupling of the client from the DBMS, which leads to increased portability.

This decoupling can be a drawback. Many vendors supply extended facilities in their DBMS products (such as stored procedures, triggers, procedural extensions to SQL, or nonstandard functions), which are of course nonstandard and are therefore not directly accessible using ODBC. So ODBC has a pass-through mechanism that permits nonstandard SQL requests to be submitted by a client directly to the ODBC driver without being intercepted, checked, or modified in any way. Back to vendor lock-in!

Java Database Connectivity

Java Database Connectivity (JDBC) is a similar model to ODBC except that it is aimed at the Java programming language rather than at C or C++. The JDBC driver manager uses a JDBC driver to convert client requests into a format suitable for transmission to the target DBMS and to convert data from the DBMS back into JDBC format.

JDBC defines several categories of driver. Type 1 involves using the JDBC-ODBC bridge supplied with the JDK and an ODBC driver. The bridge converts JDBC requests into ODBC requests, and the ODBC driver is then used to access the DBMS. At the other end of the spectrum, Type 4 drivers are written in "pure Java" and use the vendor's proprietary formats and protocol for sending and receiving data. Types 2 and 3 are hybrids of Java and non-Java code. Most modern Java applications use Type 4 drivers to access a database.

ADO and ADO.NET

ODBC was fine at the time, but it had its limitations. By the mid-1990s, Microsoft realized that other nonrelational databases (or data sources, as Microsoft prefers to call them) did not fit into the ODBC model of processing. Microsoft decided to create a new API that encompassed relational and nonrelational databases, and the concept of Universal Data Access (UDA) was born.

Microsoft's architecture was called OLE DB (pronounced "olay dee bee") and comprised three parts . The upper part defined a consumer interface, and the lower part defined a provider interface. The bit in the middle was the OLE DB infrastructure supplied by Microsoft that connected the two halves . The idea was that data source vendors would provide access to their systems and implement the provider interface. Microsoft itself created an OLE DB provider that could convert OLE DB requests into ODBC calls, allowing continued (albeit a little slower) access to relational databases even if the corresponding vendor had not yet implemented an OLE DB provider. Developers writing programs that needed to access a database could use the consumer interface. The consumer interface was still a bit low-level for many programmers, so Microsoft built another, more abstract layer on top, called ActiveX Data Objects (ADO).

The neat thing about ADO was that you could easily use it from Visual Basic. (ODBC was more difficult to use because the API was designed for C programmers; the OLE DB consumer interface was designed for C++ programmers.) Abstractions in ADO included objects for handling connections to the data source, commands (which could be SQL statements or something else, depending on the data source), and Recordset objects (which you can think of as data in a tabular format). ADO also exposed events, allowing a program to submit a command to a data source and then do something else while the command was processed . When the command completed, the program would be notified using an event, and the program could determine whether the command was completed successfully. Events were used in other parts of ADO as well.

With the advent of .NET, Microsoft decided to update ADO and created ADO.NET. ADO.NET contains several enhancements over the original ADO architecture, providing improved interoperability and performance. If you're familiar with ADO, you'll notice that the ADO.NET object model is a little different. For one thing, it has no Recordset objects ”Microsoft has created the DataAdapter and DataSet classes to support disconnected data access and operations. Using these classes allows for greater scalability because you no longer have to be connected to the database all the time. (To be fair, ADO also provided disconnected Recordset objects, but their use was the exception rather than the rule, especially among inexperienced programmers!) This means that your applications can consume fewer resources. The ADO.NET connection pooling mechanisms allow database connections to be reused by different applications, thereby reducing the need to continually connect to and disconnect from the database, which can be time-consuming .

Although you can use JDBC from J#, ADO.NET's close integration with Windows makes it the natural choice for accessing data in J# applications.

I l @ ve RuBoard


Microsoft Visual J# .NET (Core Reference)
Microsoft Visual J# .NET (Core Reference) (Pro-Developer)
ISBN: 0735615500
EAN: 2147483647
Year: 2002
Pages: 128

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net