Diffgrams
Introduced with the ADO.NET support in the .NET Framework, Diffgrams are similar to updategrams but solve some of the most serious problems inherent in updategrams. Most importantly, Diffgrams provide object-model support through the ADO.NET DataSet object. You can generate Diffgrams directly from a DataSet definition by persisting the DataSet in Diffgram format, and you can create a DataSet from a persisted Diffgram. Therefore, when you build your business logic, you don't have to write the code to generate the Diffgram or to navigate the Diffgram structure. Instead, you just use the DataSet object to write the code. You can also combine a DataSet object with a DataAdapter object to commit changes expressed in the Diffgram to the database. (DataAdapter is an intermediary object in ADO.NET that reads data from—and resolves changes to—a database.) Additionally, DataAdapter supports updates through stored procedures and can raise an event to your program if a concurrent update has been made to the data. Although Diffgrams are significantly more convenient for programmers than updategrams, using Diffgrams carries some caveats.
First, you need the .NET Framework to take full advantage of Diffgrams. The .NET Framework and the Common Language Runtime (CLR) aren't yet fully deployed, so a Web client might not have access to the DataSet's rich functionality, or the .NET Framework might not be available on a middle-tier server. Second, Diffgrams don't support updates on tables that use identity columns. If your database schema uses identity columns to automatically generate unique IDs for entities that are subsequently used for foreign keys in other tables, Diffgrams fail to process the updates. For example, Diffgrams can't successfully add line items to your database when an order and its line items are stored in separate tables and when an identity column (e.g., an order number) is used as a foreign key in the LineItems table to refer to its associated order. The only workaround is to write the update code yourself, which negates the value of Diffgrams. More subtle obstacles include the Diffgram's inability to consume XML when different complex types (defined in an XML Schema Definition—XSD) use the same name but in a different context. For example, you might use the name Vendor to reference generically a ServiceProvider type and a ProductReseller type, which have different structures. You might also encounter difficulties interpreting a Diffgram if the client uses a different schema—or no schema at all—to build the DataSet. Because the Diffgram is a serialization of a DataSet's contents, the Diffgram you receive might not match your database or any schema that you know, and consequently, updating your database becomes difficult or impossible.
If the .NET Framework isn't available, a Web client application typically has to generate a Diffgram by writing the code to construct the Diffgram format. However, on the middle tier, a processing alternative is available. SQLXML 2.0 and 3.0 can process a Diffgram and update your database in two ways: through ADO's XML dialect, which uses a CommandStream object, or through a SQLXML virtual directory, which processes Diffgrams in much the same way it processes XML templates. Both methods use an XSD mapping schema to map the data inside the Diffgram to the database structure. Using this mapping information, SQLXML processes the Diffgram and generates SQL statements to modify the database in the same way it processes an updategram. Although SQLXML will help you understand the kind of support available for Diffgrams before you install the .NET Framework, you still have to grapple with the problems I outlined earlier for updategrams and Diffgrams.
Use Diffgrams Selectively
Diffgrams are more useful than updategrams because ADO.NET generates Diffgrams automatically. But you should use Diffgrams only when your database doesn't refer to identity columns that have foreign keys and when you can control the XML schemas that the client code uses. When those two conditions are met, you can ensure successful interpretation of the Diffgrams that your Web application receives. Perhaps someday, a standard language will express changes to the data as it is represented in the XML document as opposed to expressing the changes based on the way a programming model operates on the data. Then, we might be able to rapidly build Web applications that interchange data—and changes to that data—across platforms, languages, frameworks, and database management systems.
End of Article
Prev. page
1
[2]
next page -->
