From the Editor-in-Chief of PowerBuilder Developer's Journal

Bruce Armstrong

Subscribe to Bruce Armstrong: eMailAlertsEmail Alerts
Get Bruce Armstrong: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java Developer Magazine

Java Developer : Article

DataWindow.NET Pet Shop

It's easy and productive

In the early days of Java, a sample application called Java Pet Store was introduced as a "blueprint and guideline" for Java development. A few years later when Microsoft introduced .NET, they also provided a similar sample application to demonstrate preferred methods of coding for .NET called .NET Pet Shop. That has subsequently resulted in a bit of warfare as the two camps attempted to demonstrate why their implementation was a better, higher-performance implementation.

To provide a sample of using DataWindow.NET, I took a look at the .NET Pet Shop with an eye toward demonstrating how to use DataWindow Objects and DataStores in the data access layer. I won't claim that this particular implementation qualifies as a blueprint or guideline, or that it performs better than the original .NET implementation. What I do hope to show, however, is how easy and productive it is for you to use DataWindow.NET technology for database access.

Obtaining .NET Pet Shop
If you're going to walk through this with me, the first thing you'll have to do is get a copy of the .NET Pet Shop 3.0 from Microsoft at http://msdn.microsoft.com/library/en-us/dnbda/html/petshop3x.asp.

The installer for .NET Pet Shop will automatically create the necessary tables and other database objects in either Microsoft SQL Server or Oracle. One of the things we'll be looking at later is adding support for Sybase Adaptive Server Anywhere, but for the initial install you'll need one of those other two databases. There are evaluation copies of both available from their respective company's Web site.

The .NET Pet Shop Architecture
As the diagram from the .NET Pet Shop site indicates, this latest version of .NET Pet Shop has been abstracted into three tiers. The presentation tier is implemented in Web Forms that will run in your browser. That talks to a business-logic tier in the Web server, which in turn talks to a data access layer that is responsible for communicating with the database server. To support database portability, Microsoft included a data access layer (DAL) factory class that is responsible for determining which database vendor product it needs to talk to and then creates an appropriate DAL class specialized for that particular database.

That particular architecture suits our needs well. As we use DataWindow.NET technology to handle data access, we simply create additional DAL classes for that particular database - we don't have to touch any of the other code. (The source code for this article can be downloaded from www.pbdj.sys-con.com.)

Look Ma, No OLEDB!
One of the first things we'll do is examine the custom DAL class to determine what kind of operations we'll be implementing with DataWindow.NET components. One of the big surprises you'll encounter when you do that is that the custom DAL classes don't use any OleDbConnections. They also don't use any of the advanced data classes (DataAdapter, DataSet, DataTable) that you come to expect from an ADO.NET-based application. A clue this was coming was the database-specific DAL classes, as the advanced data classes were meant to provide a level of abstraction that was supposed to make database access uniform across providers. Therefore an implementation using those advanced classes would have not required database vendor-specific DAL classes.

The reason those advanced data classes weren't used is explained on the .NET Pet Shop site in a section entitled "Database Portability." Because they were concerned about performance, they elected to use each of the individual vendor's .NET managed providers. They indicate that the .NET-managed providers are two to three time faster than the OLEDB provider.

What it also means, besides having to provide a custom DAL class for each database vendor, is that the custom DAL classes are also full of embedded SQL. Take a look, for example, at the Account.cs class for one of the custom DAL classes and you'll find quite a number of public constant declarations that look something like Listing 1.

More Stories By Bruce Armstrong

Bruce Armstrong is a development lead with Integrated Data Services (www.get-integrated.com). A charter member of TeamSybase, he has been using PowerBuilder since version 1.0.B. He was a contributing author to SYS-CON's PowerBuilder 4.0 Secrets of the Masters and the editor of SAMs' PowerBuilder 9: Advanced Client/Server Development.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Tanveer 08/29/05 11:12:27 PM EDT

Excellent article.
I have a question from where i can download source code for this article.
i dont see any link to download @http://pbdj.sys-con.com