Battle of the Visual Masters
By David S. Linthicum
Delphi vs. Visual Basic vs. Power Objects.
In early 1995, as Microsoft's Visual Basic entered its fifth year, the crew in Redmond found its dominance of the visual client/server rapid application development tool marketplace challenged by Borland's innovative Delphi 1.0. With every capability of Visual Basic plus a few, Delphi exploded onto the market with such a bang that it sent the boys in Seattle back to their compilers. Thus, we now have the Windows 95-compatible 32-bit release of Visual Basic, release 4.0.
There was, however, another challenger waiting in the wings. Oracle's very own Visual Basic "wannabe," Oracle Power Objects 1.0. Power Objects is clearly Oracle's attempt to build a Visual Basic clone, and its hope is to lure existing Visual Basic developers into its waiting arms. Power Objects is the youngest of the three tools, now at version 1.0.
Not to be outdone by Microsoft or Oracle, Borland again came on strong with its 32-bit, OLE-enabled 2.0 release, the newest revision of the bunch. Microsoft is already working on Visual Basic 5.0, and it shouldn't be long before we see the next version of Oracle Power Objects as well. The battle of features and functions continues.
If it sounds like the type of battle you see between long distance companies, you're right. This is a battle for the hearts and minds of client/server developers, and the combatants are willing to do almost anything to win. The question you need to answer is: Which tool is right for your client/server project?
Just for the fun of it, let's place Visual Basic, Delphi, and Oracle Power Objects side by side. Let's test development capabilities, database support, performance, and other features that really matter. May the best tool win! (I should state here that my description of Power Objects in this article is based on a version I downloaded from the Web, because Oracle's public relations representatives failed to release a shrink-wrapped version of Power Objects to me in time for this article.)
From 35,000 feet, these tools look very much alike. All provide advanced visual development environments, the ability to use OLE components (OCXs), built-in links to a variety of database engines, and an underlying programming language. Upon closer examination, however, the similarities abruptly end.
Visual Basic was one of the first rapid application development (RAD) tools that brought drag-and-drop component-based development to Windows 3.1, and now to Windows NT and Windows 95. Visual Basic's experience shows in the current release, which rides on OLE exclusively. Using the power of OLE automation, Visual Basic developers can not only access and link to OLE automation servers, they can create OLE automation servers (in-process and out-of-process) that are accessible from other OLE-enabled applications. What's more, Visual Basic developers can create automation servers that are accessible over a network, and thus provide an application partitioning mechanism for multi-tier development.
If you know how to use Visual Basic, you'll have no problem using Oracle Power Objects. Unlike the other players, Power Objects supports both Macintosh and Windows environments, but it does not offer support for the politically correct ODBC. It provides native database drivers only. Power Objects uses Visual Basic's application development language (Basic), and can use OCX components as well. There is no VBX support, however.
Delphi is the radical of the bunch, with Object Pascal as the underlying development language. Like Visual Basic, Delphi (with the 2.0 release) provides both in-process and out-of-process OLE automation services, and can use OCXs in its applications. The most important feature of Delphi is what it doesn't do; namely, it does not use a p-code interpreter. Both Visual Basic and Power Objects require that runtime applications pass through an interpreter, which means slower applications and more system resources. Delphi compiles its application to an optimized native executable that runs like the wind, and eats fewer memory chips and processor cycles.
All of these products come in different versions that enable developers to match the tools, and the price of the tools, to the application. Power Objects comes in both a client/server version (with links to database servers) and a standalone version. Delphi offers Delphi Desktop for individual developers, Delphi Developer for professional LAN-based developers, and Delphi Client/Server for client/server developers. Visual Basic offers similar packages, including a Standard Edition, Professional Edition, and Enterprise Edition.
All three tools support component-based development, or the ability to build applications by assembling component parts. In fact, all of these tools rely more on component-based development than on object-oriented features such as inheritance and encapsulation. This seems to be an easy development model for beginners to follow. However, each tool supports objects in its own special way.
Component parts are either native components (or objects) that are not portable from one tool to another, or third-party components (such as VBXs or OCXs) that are portable from tool to tool. The general idea is to use as many prebuilt components/objects as possible before creating your own native components, or to use third-party components to add flare to your client/server application, such as including a calculator, VCR controls, or mainframe access.
Third-party components once dominated by Visual Basic Custom Controls (VBXs) gave way to OLE Custom Controls (OCXs). Why the change? VBXs were not based on a standard component-based development platform, and thus declared a "kludge" by those tasked with building these mini applications. OCXs, in contrast, use standard component-construction mechanisms and interfaces based on OLE. Visual Basic still supports VBXs, as does Delphi; Power Objects supports OCXs only.
Delphi's component-based development architecture provides developers with the best of the object-oriented and component-development worlds. Delphi is written using its own library of components and tools. Application construction is simply a matter of building upon Delphi's application framework. This framework, called the Visual Com Library (VCL), is a set of object types that provide the foundation for an application, so you don't have to build objects from scratch.
The VCL provides everything you need to create user interface objects for viewing and changing data, list boxes, combo boxes, and menus. The VCL also provides a basic set of components such as grid, tab, and notebook objects. As with Visual Basic and Power Objects, Delphi developers select components from a palette and drag them onto the application work area.
Delphi lets developers take components as-is, or they can extend a component's capabilities via inheritance. Developers create a new component by inheriting features and functions from existing components on the VCL, and change the components to meet the exact needs of their applications.
Creating components with Delphi is simply a matter of inheriting from an existing component type, defining new fields, properties, and methods, and registering the new component with Delphi. If you want to use third-party components (such as OCXs or VBXs) you need to register them with Delphi, so they will appear on the palette for use inside applications. (See Figure 1) The palette has a special panel for OCX controls, and Delphi automatically creates object wrappers for OCX controls so developers can use them as objects. This means that developers can create new hybrid objects from third-party components, and change object characteristics to meet application requirements. Notice how Delphi supports both Windows 3.1 and Windows 95 native control sets.
Like Delphi, Visual Basic lets developers assemble applications from a palette of components known as the toolbox. The toolbox is found on Visual Basic's Integrated Development Environment (IDE), where developers drag and drop components or controls onto waiting forms. Visual Basic uses several independent applications running concurrently to make up the development environment. (See Figure 2)
Also like Delphi, Visual Basic's toolbox is extendible through the integration of third-party OCXs. However, most developers will be happy with the components that come with Visual Basic. Once a control exists on a Visual Basic form, you can alter the properties of that control using the Properties window or Properties pages. You also have the option to set the properties of many controls at the same time using a grouping mechanism of Visual Basic.
Power Objects uses components similar to Visual Basic. (See Figure 3.) Developers can load third-party OCXs into Power Objects for inclusion on the tool palette. Keep in mind that the lack of support for VBXs may mean that you will have a tough time finding third-party components for Power Objects until more VBX vendors release OCX versions of their products.
Inside the Power Objects development environment, libraries appear in the tool as book icons, and organize the globally accessed components. To place components on forms, you select a control on a palette and drop it onto the form. As with Visual Basic, you can set properties using a properties dialog. In fact, if you're good at Visual Basic, you'll have no problem moving around Power Objects.
There is one area in which Power Objects differs greatly from Visual Basic: its support of the object-oriented development model. Power Objects bases its object on forms rather than on controls. Developers can make any form into a class and drop these classes onto other forms, thus inheriting the original form's characteristics. This is handy for applications that contain similar forms. When a developer makes changes to a form, the changes automatically propagate down to forms that inherit from that form. This is standard object-oriented functionality found in most client/server development tools.
All of these tools provide some sort of reporting capabilities. Visual Basic bundles Crystal Reports, and can add it into the tools and application as an OCX. Delphi bundles Borland's ReportSmith. Both of these commercially available report writers offer most of the reporting and business graphing capabilities you need for building complex applications. Power Objects, however, uses its own band-style report writer. This poses few problems with banded reports, but is somewhat awkward when creating complex reports. If you go with Power Objects, you should think about using another report writer (such as Crystal Reports, which integrates into Power Objects as an OCX).
Regarding the programming languages, you'll find that Visual Basic and Power Objects use an almost identical version of Basic. (Power Objects' version is known as Oracle Basic.) Both Basic languages are easy to use and understand. Delphi, unlike other tools on the market, uses Object Pascal. If you've taken Pascal in college, you'll find Object Pascal not much different. However, if you are learning from scratch, using a 3GL is not always desirable. (See Figure 4.)
All three tools can access a number of database engines, both local and remote. However, each approaches database access in its own unique way.
Delphi's Data Access pages provide Delphi objects for database access. For instance, you'll find the database objects that you need to connect to a database engine, access the tables, and query the database on behalf of the application.
The Borland Database Engine (BDE) is at the core of Delphi's database architecture. Delphi uses the BDE, including native database drivers, to access information on Oracle, Sybase, Informix, Interbase, DB2, and Microsoft SQL Server databases. You can also get to database files such as dBASE and Paradox through the ODBC standard interface. Delphi 2.0 has encapsulated much of BDE into high-level objects that you can edit visually in the application design environment. Of the three products, Delphi gives developers the most flexibility for database access. New with Delphi 2.0 is a database design facility that lets developers create and modify databases without having to use a third-party tool. If you need to browse and edit domains, triggers, and stored procedures, Delphi provides SQL Explorer. However, it is available only in the Client/Server Edition.
Visual Basic database access is built on top of the Data Access Object (DAO) and the JET (Joint Engine Technology) database engine. In addition, Visual Basic provides other database features, such as enhanced data control, new bound controls, and a database forms generator. Visual Basic's Database Manager offers complete control over any database engine that Visual Basic can connect to through 32-bit ODBC.
Through Visual Basic, JET supports the creation, modification, and deletion of tables, indexes, and database queries. Visual Basic and JET coordinate database access for Visual Basic applications using DAOs. DAOs provide developers with the ability to manipulate information in the database using the properties mechanisms of Visual Basic. Although data access from Visual Basic always seemed to be an afterthought, with version 4.0 it's clear that Visual Basic is finally serious about client/server development.
In addition to typical database operations, Visual Basic and JET provide special features such as data replication. This enables the developer to make entire copies of the database, and adjust for data and schema differences on the fly. Security is a feature as well, and JET allows the entire database to be password protected.
Power Objects is clearly the product of a database server company: ODBC is nowhere to be found. Instead, Power Objects uses native database drivers for Oracle, Sybase, and Microsoft SQL Server. Therefore, if your database is not among the privileged few, you're out of luck. However, Power Objects insists on complete control of the database engine, something that ODBC has difficulty with. Fortunately, ODBC support will be a part of the next release of Power Objects.
Power Objects pushes all database requests through a session object. The session object creates the connection to the database and visually places all accessible tables, views, and indexes on the workspace. Different icons represent different types of database resources. This visual representation of database resources is easy to use, more so than the other two.
After creating your database links, you can drag tables and views onto forms. This creates a bound record source between session objects and Power Objects containers. Most of the Power Objects controls can bind to the database, including list boxes, pop-up lists, and radio buttons.
Other database features of Power Objects include the ability to toggle locks from optimistic to pessimistic, and developers can control buffers for better integrity control. Also, Power Objects, like Visual Basic, provides the ability to move data and schemas from one database to another. This is Power Objects' "upsizing" strategy.
All three products offer local database engines, so developers don't have to hook up their applications to full-blown database servers to get started. Delphi provides a Windows version of Interbase, Power Objects provides Oracle's Blaze database, and Visual Basic provides local file access using ODBC. However, Blaze can't handle compound indexes.
OLE Automation Fever
A common theme among these three tools is support for OLE automation, both as clients and servers. Simply put, this is the ability of one application to provide services to another application through a common interface. For instance, using OLE automation, Visual Basic can use Microsoft Access as a report server, or you can send the results of a database query from Delphi to Microsoft Excel.
Visual Basic is one of the few tools that can extend the capabilities of OLE automation across a network. Using remote OLE automation, Visual Basic developers create a multi-tiered application with portions of an application running on remote servers as OLE automation servers. This enables developers to "partition" an application on as many application servers as required to meet the scaling requirements of the application. Although remote OLE automation provides an advanced application distribution mechanism for Visual Basic, it's difficult to set up. In reality, remote OLE automation is a precursor to Microsoft's upcoming Network OLE. If you want to use OLE automation for partitioning purposes, you may want to wait.
You will find support for OLE automation in Delphi 2.0. Delphi uses a new type called "variant" to provide transparent integration to OLE automation servers and controllers (clients). Using Delphi, you create OLE automation servers by defining an object that inherits from a type known as "TAutoObject." Next, you define some code with a new automated reserved word to expose properties and methods to other OLE-enabled applications. The identifier lets you expose properties, parameters, and function results using various types. At this point, you can create both in-process or out-of-process incarnations of an OLE automation server. If you find all of this confusing, you'll be happy to know that Delphi includes an expert that makes it easy to create OLE automation servers.
Visual Basic is the newest old hand at OLE automation. Creating an OLE automation server using Visual Basic is simply a matter of adding a new class module to the project for object definitions. Then you define the methods and properties for the server, set the "Class Public" property to True, and classify the Project StartMode as an OLE Server.
Unfortunately, Power Objects can act only as an OLE automation container. The ability to generate OLE automation servers is in the works. For now, this is the domain of Visual Basic and Delphi, or for those willing to traverse the obstacles of using a 3GL such as Visual C++.
You can break down performance for these tools into development tool performance, runtime application performance, and database performance. All of the development tools perform well on my Windows 95-based Pentium 100 with 16MB of memory. However, on slower 486s, you will notice that Visual Basic begins to lag behind Power Objects and Delphi. The reality is that all that OCX stuff built into Visual Basic means it will get along better with faster PCs.
Windows 95 with Win32 support for Delphi and Visual Basic is essential for the developer's workstation. Although both of these tools can generate 16-bit (Win16) applications for Windows 3.1, these tools exploit the multi-tasking and multi-threading capabilities of the Windows 95 and Windows NT operating systems, and can generate applications that also exploit these capabilities. Power Objects and Power Objects-based applications, in contrast, are more at home on Windows 3.11, but run fine on Windows 95.
In terms of runtime performance, there is a clear winner. Delphi generates native .exes for application distribution, while Power Objects and Visual Basic are limited by p-code interpreters. This means that not only do Delphi applications perform better, they require fewer memory chips and processor cycles. Power Objects comes in a close second, with Visual Basic right on its heels.
All of these tools provide good database performance. However, Visual Basic's insistence on ODBC does mean that your database performance will lag behind Delphi and Power Objects, both of which use native database drivers. The inclusion of 32-bit ODBC almost makes up for the additional overhead of a least-common-denominator translation layer. Delphi seems to beat the others, although it was difficult for me to determine, because the test applications ran faster, and thus could draw the data to the screen quickly. The other tools could very well have the data back from the database engine, but application performance under the interpreters delays the time it takes to move the information to a screen or report.
Picking Your Tools
The right tool for you depends on your application requirements: platform considerations, ease of development, performance, and scalability. If you need Windows 95 or Windows NT 32-bit compatibility, your choices are limited to Visual Basic and Delphi. Both provide Win32 support, including support for multi-threading and multi-tasking. However, if you need to move your application between the Windows environment and the Macintosh, Power Objects is your only choice.
All of these tools enable developers to build applications quickly and with little effort. Visual Basic just barely surpasses Delphi and Power Objects with its quick ability to get applications up and running. Delphi's development environment is powerful, but it is a tad more complex to deal with as a novice. Power Objects is also a competent development environment, but it has a few kinks, such as the lack of a static menu, toolbar, and status line objects, as well as a limited number of OCXs. Both Visual Basic and Delphi are rich in components, and they have lucrative third-party native component markets that enable developers to create applications through integration, not perspiration.
If performance is your most important application requirement, then your choice is Delphi, hands down. The application deployment mechanism is the best in the business, and it lets you place true native executables on desktops rather than relying on p-code and interpreters. Borland seems to be keeping this trick to itself. The only way to match the performance of a Delphi application is to use a native 3GL and a compiler.
If you want scalability, then Visual Basic and Delphi are the contenders. Visual Basic's remote OLE automation servers are the first to offer easy application partitioning (multi-tier development) using OLE. However, you should know that this is not the Network OLE that Microsoft will eventually deliver. You should also know that this is bleeding-edge stuff, and it's going to take some time and trouble to build and set up remote OLE automation servers. Delphi provides you with the ability to create OLE automation servers with a migration path to the Microsoft OLE infrastructure when it finally hits the streets.
The good news is that all three of these competitors plan major upgrades in the near future, and you can count on great things from each. The bad news is that you'll have to sift through the new capabilities to find what your application really needs.
David S. Linthicum is a technical manager with EDS in Falls Church, Virginia. He's the author of several books on software development, a speaker, and an associate professor of computer science at a local college. You can email David at firstname.lastname@example.org, or visit his home page on the World Wide Web at http://ourworld.compuserve.com:80/homepages/D_Linthicum/.
Reprinted with permission from DBMS Magazine, April, 1996, Vol. 9, No. 4, Copyright © 1996 Miller Freeman, Inc., ALL RIGHTS RESERVED