Introduced in 1991 and patented in October 1996, PowerBuilder's DataWindow technology remains one of the most flexible, dynamic, and versatile means for data retrieval, modification, and presentation available in any development tool. By launching DataWindow.NET along with PowerBuilder 10 later this year, Sybase is continuing its commitment to the four-phased .NET strategy announced in 2002.

DataWindow.NET is a separate product offering that brings PowerBuilder's hallmark technology to the growing number of programmers in Microsoft's.NET environment, including those using development tools such as Microsoft's Visual Studio .NET, Borland's C#Builder, and the open source #develop (SharpDevelop). In this two-part article we'll look at the overall design of this exciting new product as well as work through a simple example in C#.

Author's note: This article was written late in the Beta 1 cycle of PowerBuilder 10 and so some details may not completely or accurately reflect what is delivered in subsequent beta cycles or when DataWindow.NET becomes generally available.

High-Level Architecture
The primary functionality of the DataWindow is concentrated into two .NET assemblies (see Figure 1), DataWindow.DLL (built in C#) and DataWindowInterop.DLL (built in managed C++), as well as the core DataWindow server engine, PBDWN100.DLL, which is built using unmanaged C++. Since PowerBuilder shares the core DataWindow engine, the behavior of the DataWindow in the .NET environment will be nearly identical to that of PowerBuilder. This design approach is in sharp contrast to that of the Java DataWindow implementation that was formerly delivered with Sybase PowerJ, an implementation that many feel included an inadequate subset of the PowerBuilder DataWindow functionality.

In addition to the two DataWindow assemblies and the core engine, the OLE-DB, ODBC, and native database (Oracle, Sybase ASE and DirectConnect, and Informix) drivers familiar to PowerBuilder developers are included. These drivers are identical to those delivered with PowerBuilder and so offer the same feature set and performance that you are accustomed to within PowerBuilder applications.

To those well-established connectivity options, Sybase is introducing a new ADO.NET driver allowing .NET programmers to use a single database connection seamlessly across various programming constructs including Command objects, DataSets, DataTables, DataViews, and, of course, the Sybase DataWindow. The ADO.NET driver implementation consists of a .NET assembly (PBDATA100.DLL) as well as an unmanaged driver library (PBADO100.DLL) that parallels the implementation and feature set of the other PowerBuilder native database interfaces.

Also being delivered is DataWindow Designer, a graphical user interface for developing DataWindow objects. This product is a modification of the now discontinued DataWindow Builder, which was essentially a standalone PowerBuilder DataWindow painter that Java DataWindow developers could use to create DataWindow objects without the need for the complete PowerBuilder product. PowerBuilder developers who also plan to use DataWindows in .NET applications can bypass this tool and use the PowerBuilder 10 environment instead.

DataWindow Object Model
Figure 2 shows a portion of the DataWindow object model generated via the reverse-engineering features of Sybase PowerDesigner 10. It highlights the four interfaces and the three main classes that constitute the DataWindow. In addition to these classes and interfaces, there are two transaction classes for accessing back-end databases as well as delegates (or event handlers) and exception classes to round out the implementation. We'll look at all these aspects next.

DataWindow Interfaces and Classes
As you can see from the object model diagram in Figure 2, three of the four interfaces correspond directly with the three main classes: DataWindowChild, DataStore, and DataWindowControl. We'll briefly explore the interrelationships of these interfaces and classes.

IDataWindowBase/DataWindowChild
The root interface is IDataWindowBase, which includes the subset of methods shared by all three classes including Retrieve, UpdateData (yes, there are some naming changes!), and the familiar family of GetItem and SetItem methods. The DataWindowChild class directly implements this interface, whereas the DataStore and DataWindowControl classes do so indirectly by implementing separate interfaces that extend IDataWindowBase.

You'll also notice that DataWindowChild is a class and extends the basic .NET System.Object class. Compared to PowerBuilder, where DataWindowChild extends a PowerBuilder structure, this is not a true class.

IDataStore/DataStore
The IDataStore interface extends IDataWindowBase by adding properties and methods appropriate for a DataStore (and DataWindow control) but not available for a DataWindow child. These include the LibraryList and DataWindowObject properties, which are used to specify the DataWindow object definition assigned to a specific instance of a DataStore or DataWindow control. Also defined on IDataStore are a number of events that will appear familiar, albeit with some naming changes to reflect standard .NET naming conventions (e.g., Begin Retrieve in lieu of PowerBuilder's RetrieveStart, BeginPrint for PrintStart, and BeginUpdate for UpdateStart).

The DataStore class extends the .NET System.ComponentModel.Component class, which in turn extends System.MarshalByRefObject, thus fulfilling one of the requirements for allowing DataStore instances to be used across domain boundaries in applications that support remoting, which is the .NET approach to building distributed applications.

IDataWindow/DataWindowControl
Further refining IDataStore is the IDataWindow interface that incorporates the methods and events that have visual context in a DataWindow control such as scrolling, selecting a row, and changing the column that has input focus. The DataWindowControl class also implements a second interface, IDataWindowGraph, which includes all of the graph-related methods such as SetSeriesStyle, FindCategory, and DataCount.

The DataWindowControl class extends System.Windows.Forms. Control, which includes classes such as buttons, labels, the list view, and numerous other widgets familiar to developers of rich-client applications.

The progressive refinement of functionality gained through the inheritance hierarchy of the three main interfaces offers some powerful capabilities that even PowerBuilder developers do not currently have. Have you ever had to duplicate your PowerBuilder code because you need to apply the same operation, say a sort, to both a DataStore and a DataWindow control? When programming in a .NET language, you can build methods that accept an argument of IDataStore, so at runtime either a DataWindow control or a DataStore can be passed in.

Transaction Classes
Complementing the interfaces and classes that contain the implementation of the DataWindow and DataStore are two additional classes that facilitate the connectivity from the DataWindow objects to a database. These classes are illustrated in the object model diagram shown in Figure 3.

Transaction
The Transaction class is analogous to the Transaction object in PowerBuilder. Most of the properties should appear familiar, as will the DbmsType enumeration options that in PowerBuilder are provided as strings to the DBMS property of the Transaction object. The Transaction class in the .NET product provides direct object methods for database connectivity and transaction management as opposed to the PowerScript statements of CONNECT, DISCONNECT, ROLLBACK, and COMMIT, each of which accepts an optional USING transaction-object clause. You'll also notice that the syntax-from-SQL functionality is retained in the .NET environment, thus offering the same capabilities to create DataWindows "on-the-fly" as in PowerBuilder.

AdoTransaction
One of the disadvantages of using the Transaction class is that it cannot be shared by other .NET database constructs such as DataSets or Command objects, and that's where the Sybase.DataWindow.AdoTransaction class comes in. AdoTransaction is modeled on the System.Data.IDbCommand interface that every ADO.NET provider implements. Specifically, AdoTransaction encompasses: