Ken Spencer

Windows DNA Then and Now

Download the code (12KB)

his month I'll discuss why and how you should use Microsoft® Windows® DNA (including COM). Along the way I'll touch on Windows DNA 2000, Microsoft's new name for their n-tier technology.

Figure 1: Windows DNA Architecture

Now, what the heck is Windows DNA all about? Figure 1 shows the standard graphic that Microsoft uses. Here is how Microsoft defines Windows DNA: "Microsoft Windows Distributed interNet Applications Architecture is the application development model for the Windows platform." The current version includes: Technologies provided by Windows NT® Server, such as Microsoft Internet Information Server (IIS), ASP, and NTFS SNA Server Site Server Commerce Edition SQL Server™ 7.0 Visual Studio® 6.0       So Windows DNA is not a product, but a collection of products and technologies. You can use any or all of these technologies to build your Windows DNA-based application and take advantage of the various services that Windows DNA offers.       According to Microsoft, Windows DNA 2000 is "a comprehensive, integrated platform for building and operating state-of-the-art distributed Web applications, as well as the next wave of Internet-based Web services." What does this mean to developers? Windows DNA 2000 is a family of solutions that can be used to solve your development problems. Windows DNA 2000 includes: Windows 2000, including the COM+, IIS, clustering, and IP load-balancing services Microsoft Commerce Server 4.0 Microsoft BizTalk™ Server Microsoft Integration Server (codenamed Babylon) Microsoft AppCenter The next generation of SQL Server (codenamed Shiloh) Visual Studio       The various products in this list are either shipping or should be available in the next year. They're all designed to work together and make your applications easier to build and maintain.       You can also mix and match software in your applications using Windows DNA. Today you may be using Visual Basic® 6.0 and SQL Server 7.0 running on Windows NT 4.0. You can port SQL Server 7.0 to Windows 2000 and still have a hot Windows DNA-based application. Then you should be able to migrate to Shiloh, the next version of SQL Server, at some point in the future. Likewise, you can migrate your existing applications to Windows 2000 and take advantage of the other Windows DNA 2000 services. The Tiered Architecture       Applications are broken down into what is typically called a tiered or layered architecture. A tier normally consists of a particular type of software. For instance, in a typical client/server relationship, the client is one tier and the server is the second tier. In reality, the tiers used in any business system will be more vague than a simple list and will likely bleed over from one tier to another. The introduction of COM and DCOM in particular calls for a rethinking of the multitier model. In a typical client/server environment in Visual Basic, the client may be running tier 1, which is the user interface; tier 2 is a database class library (such as ActiveX® Data Objects) implemented as a DLL; the server system is running SQL Server as tier 3; and a fourth tier of agents may be running on the server.       Most people break the tiered model into several parts, usually consisting of three layers. The first tier, user services, includes the application interface and the GUI portion of applications. The second tier, business services, is where business rules are enforced. Data services, the third tier, is the lowest level. It performs the direct manipulation of data. In addition to these three layers, you may create other layers or components that your application requires. Each layer is responsible for handling specific functions within the system. This ensures that functionality does not bleed through multiple service layers.       Additional capabilities can be categorized into tiers as well. For example, ActiveX Data Objects (ADO) and mail could comprise their own tier or be part of any of the three main tiers. Common service types to be integrated into tiers include interface services, support services, data services, remote access services, mail services, callback services, and graphics services. Why Use Objects?       So isn't it quicker to just use ASP and ADO to crank out a quick application? I really doubt it in the long run. Why? Good development practices dictate that you should always plan what you are going to do, then execute that plan. One of my favorite old sayings is, "If you fail to plan, you plan to fail." This is what Windows DNA and objects are all about.       When you build a Windows DNA-centric application you are really building an app that consists of many different parts (objects). The beauty of this approach comes into play as you continue to build features into your applications. For instance, in my August 1999 column I showed you an application that was demoed at TechEd this past May. The FMStocks_DB project implements a component which is comprised of several classes. One of the classes, Ticker, has the following methods: VerifySymbol, GetPrice, ListByTicker, ListByCompany, and GetFundamentals.       Once you create the Ticker class and compile the component, any application you create on the machine will have access to these methods. All a developer needs to do is point CreateObject at the Ticker class and voilą, they have access to the Ticker object. No recompiling, messing with source, or anything. Just register the FMStocks-DB.dll and use Ticker.       That's why Windows DNA is so important. Once you have created an object, you can reuse it over and over again. Your development time should go way down and your maintenance costs should also decrease. How do Microsoft and other commercial software vendors build large-scale products so quickly? Objects. The Practical Side       Now let's take a look at a simple Windows DNA-centric application. This application will amaze you with its simplicity, but it will also give you a good look at the upside of the technologies. Plus, you can take the code from this column and simply use it since it is generic.       My sample Windows DNA-centric application will use one Visual Basic class—database.cls. Figure 2 contains the source for the class. Most of this code should look familiar to you if you have done any ADO programming in either ASP or Visual Basic.       Here's how you can turn this code into a COM class (object). Create a new project in Visual Basic. Select ActiveX DLL for the project type. Select Class1 in Project Explorer and open it. Add the code shown in Figure 2 to that class. Now, rename the class to Database.       Next, open the project's properties and set the project name to DB. Compile the project using File | Make DB.DLL. That's it. You have just created the DB component, which has one class called database.       The reason to create any object is to use it. Using the Database class, I created a new project to test the object. First, I added a new project to create a project group and set the project type to Standard EXE. Next, I created two references to COM components using Project References. The first is to the Microsoft ActiveX Data Objects 2.1 Library and the second is to the DB component I just created.

Figure 3: Form1 DB Component

Next, to use the component, I added three textboxes and three labels to Form1 along with a command button (see Figure 3). The controls are named according to the table in Figure 4. The default DSN information points to the Pubs DSN. You should set the DSN string to match your DSN and server security information.       Now, open the code window for cmdGo by double-clicking it. Add the code shown here to cmdGo_Click:

 Private Sub cmdGo_Click()
 Dim rs As Recordset, txtOut As String
 Dim db As db.Database

     If txtDSN > "" Then
         If txtSelect > "" Then
             Set db = CreateObject("db.Database")
             Set rs = db.RunWithRS(txtSelect, txtDSN)

             Do While Not rs.EOF
                 txtOut = txtOut & vbCrLf & rs("au_lname")
                 rs.MoveNext
             Loop
             txtOutput = txtOut
         End If
     End If
     Set rs = Nothing
     Set db = Nothing
 End Sub

Figure 5: Database Test in Visual InterDev

Also, note the addition of the PageObject DTC. This DTC was added to take advantage of the FirstEntered property. (For more information on PageObject, see my December 1998 and January 1999 Beyond the Browser columns.)       I copied the code from the cmdGo_Click event in Form1 and added it to the cmdGo_OnClick event in Database.asp. I had to make a couple of minor tweaks to the code, which is shown in Figure 6. I also created a project reference to the Microsoft ActiveX Data Objects 2.1 Library, as I did in Form1.       Next, I added the code in the OnEnter event to load the textboxes with the default values. I also tweaked the code in the OnClick event. These modifications consisted of three changes: I deleted all explicit variable declarations, added .value to all of the textbox references, and added the server prefix to the CreateObject statement. These changes can be seen in Figure 6. Finally, I saved the page and viewed it. Conclusion       So what does all this mean? Well, in the second half of this column, I created the component that contains the Database class. Now whenever you need to use ADO in a Visual Basic, Microsoft Office, C++, Delphi, or ASP application, you can use this class instead of creating all that ADO code again.       Second, you can use the Database object in other objects. You simply create the new ActiveX DLL or EXE project, then use the Database class just as I did here. It then becomes encapsulated in your new object. The only thing you must do differently is remember to include db.dll when distributing your application.       Here are a couple of other parting thoughts. First, you will probably want to enhance the Database class for your usage. You should add functions that work with stored procedures, as well as some error handling features.       Second, you might be surprised to know that using ADO from the Database class is faster than using it from script. That is because your component is compiled and ASP is not. So, using Windows DNA with COM objects can result in faster applications as well as cut down your future development and maintenance time. What's more, if you need to change the ADO code to add some new feature, you make the change in the class and both the Visual Basic-based and ASP applications take advantage of it.

From the December 1999 issue of Microsoft Internet Developer