Delphi 2 - A Comparison of Client/Server Development Tools; PowerBuilder vs. Delphi

By: Borland Staff

Abstract: Delphi offers performance vastly superior to PowerBuilder. And only Delphi offersintegrated coding, debugging, testing, and deployment of client/serverapplications to increase developer productivity and applicationstability.

A Comparison of Client/Server Development Tools; Powerbuilder vs. Delphi
By Michael Lant
Sphere Data Systems Inc.
NOTE: The views and information expressed in this document represent those of its author(s) who are solely responsible for its content. Borland does not make or give any representation or warranty with respect such content.


Summary: Only Delphi Client/Server Suite 2.0's database application architecture incorporates object oriented techniques to offer flexibility, reusability and maintainability of client/server applications.

Delphi DataModules separate business logic from database connectivity and user interfaces to offer modular construction of client/server applications.

Segregating application building into component parts means that developers leverage their specialized skill sets. This means that database developers concentrate on implementing high performance data models, while the GUI design engineers concentrate on the application front end and interaction models, while business modelers implement a consistent set of business logic for the corporation.

Planning for Three Tier:
Current thinking is leading client/server application development towards an architecture whereby business logic is distinct from server or client implementations. Servers are used to enforce fundamental and immutable rules of the business like referential integrity and constraints. Client interfaces are used to control data navigation and display. Most importantly, business rules are then implemented in a separate location so that they may be

reused from application to application
centrally maintained and easily changed
Development work may also be segmented so that members of a development team may work on the layer of the application where their talents are best suited (i.e. business rule developers, GUI designers, entity relations experts). Developers are also able to leverage their existing skills and develop the business rules in the more powerful language constructs and tools such as debuggers that don't exist in database servers. These factors all add up to higher degrees of portability, scalability, shorter development times as well as reduced training, development and maintenance costs.

Figure 2: Delphi's Separation of Data Access From Data Presentation.

A. Delphi Supports a Logical and Physical Three Tier Architecture
Delphi Client/Server Suite 2.0 provides a logical three-tier architecture mechanism for separating the problem domain from the user interface. Three important parts to this solution are:

Separating Data Access from Data presentation.
Providing a DataModule object for the purpose of centralizing and encapsulating business rules.
Providing an object model interface for database access.

1. Separating Data Access and Data presentation creates reusable code
Delphi formally separates data access from the presentation of data resulting in an isolated area to maintain business rules. Table, Query, and Stored Procedures objects are the basic data access components for client/server applications. They provide navigational and query interfaces to any database. All three of these object types share certain characteristics and are therefore implemented from a common class known as a DataSet.

DataSet objects connect with the tables, views, etc. of the database, pass SQL commands to the database and automatically implement advanced data management scheme for the returned data. DataSet components also allow field level access to the returned data as well as the ability to navigate and perform operations on the data. At run time, they have no visual representation.

Because of the componentization of the Delphi Database architecture, business logic can be applied to Tables, Stored Procedures, and Queries by creating methods on Before and/or After events such as: posts, deletes, inserts, and edits. This allows you to create new business objects via customization.

Figure 3: Delphi Client / Server Suite 2.0's new reusable Data Module Objects encapsulate Business Rules.

DataSet components feed data to Data Aware components such as grids, drop down lists, ComboBoxes etc via a DataSource. Data Aware components provide the interface through which users view and modify data. The developer is free to use any Data Aware components in any combination and in any arrangement desired unlike the restrictive DataWindow.

Figure 4: Delphi Logical partitioning of reusable Business Rules

Conclusion: Unlike the DataWindow, Delphi componentizes data access, data visualization and business logic. This simplifies the client/server architecture, reduces the learning curve, and increases the flexibility in which to enhance your application building environment.

2. DataModules - Logical Partitioning of Business Rules
New to Delphi 2.0 is the Data Module object. The DataModule provides a formal mechanism for collecting and encapsulating, DataSet objects, their attributes, and events and code (business rules) in one central location. The data module, like any other object in Delphi, may be reused in the same application or within other applications. This ensures consistent implementation of business rules across any client/server application. DataModules are fully object oriented and may be inherited from to create a solution to another business situation.

An example of this might be the creation of a base data model that provides basic services such as logging onto a server and system level services typically found in a framework. All database specific data modules would descend from this base Data Module object and inherit the base data model capabilities.

The Data Module allows developers to create a logical n-tier application environment by centrally locating business logic. This is a solid foundation for physical support of distributed applications. Support for physical n-tier application and server architectures is currently available for Delphi through third party libraries such as IBM's CICS, ATT's TopEnd, Novell's Tuxedo, Digital's Object Broker, Orbix's IONA and others.

3. Network OLE and Remote Automation technology:
In the Windows environment, Microsoft operating system technologies such as Visual Basic 4.0's remote automation and the forthcoming Network OLE can be used to distribute application logic among servers. Because Delphi Client / Server Suite 2.0 fully supports these technologies and can create high performance OLE automation controllers and servers, Delphi will allow developers to create partitioned applications easily across Windows 95 and NT.

4. Open Environment's Entera:
With Borland's recent acquisition of Open Environment, comes the Entera product line. Entera includes a range of open, scalable tools which provide multi-tier, distributed computing support and connectivity for enterprise developers. Entera dramatically simplifies the process of creating enterprise applications by reducing the complexity of distributed computing technologies such as RPC (Remote Procedure Call) based communications, distributed computing services (CORBA, DCE, DCOM), access to enterprise databases (Oracle, Sybase, Informix, DB2, Ingres, Rdb, EDA/SQL) and mainframe applications (IBM 3270, DEC VT100). Entera provides a completely scalable and reliable distributed computing architecture and has achieved high satisfaction ratings from large corporate accounts as well as praise from industry analysts.

Borland and OEC's technologies are completely complementary and can be readily combined. Customers such as T. Rowe Price have already integrated Delphi Client/Server Suite with Entera through its function call API to create sophisticated enterprise applications. Additionally, OEC has demonstrated their forthcoming OLEnterprise technologies working with Borland's Delphi Client/Server Suite at trade shows generating high interest and positive reactions. OLEnterprise extends Borland's development tools to immediately take advantage of OEC's open connectivity and scalability through Microsoft's OLE standard.

OLEnterprise provides direct interoperability with Microsoft DCOM (Distributed Common Object Model) thereby providing complete integration with Windows development tools and applications running on the desktop. OLEnterprise includes OLE Gateway which effectively extends OLE from being a Windows-only solution. OLE Gateway supports RPC and CORBA to provide a reliable, open distributed computing solution enabling Windows development tools to integrate information systems from a range of Unix and mainframe environments. Customers are able to take advantage of Entera's scalable distributed computing capabilities including security and directory services while adhering to open standards. With the broad penetration of Windows, OLEnterprise provides an easy entry point for developers seeking to extend their client/server applications to the enterprise.

Conclusion: Delphi Data Modules provide a mechanism for the encapsulation and reuse of business rules that is distinctly superior to that of PowerBuilder. The DataModule allows Delphi developers to maximize code reuse in a simple, straightforward manner, while minimizing bugs and recurring maintenance issues. Borland's acquisition of Open Environment Corp provides the technology necessary to dliver a scalable architecture for the entire enterprise.

B. DataWindow Limitations
PowerBuilder's DataWindows combine several discreet functionalities into a single object: access to the database server and presentation of data in the user interface. The single object approach has some distinct drawbacks:

Applications carry the overhead of unused functionality of the DataWindow.
DataWindows are not object oriented.
By including multiple functionalities into a single object DataWindows do not follow good object-oriented design.
To effectively learn and then use a DataWindow, the developer must understand the complex interactions of different functionalities.
DataWindow functionality cannot be extended easily. For example, third parties very rarely supply a new DataWindow presentation style.
Optimizing a data access by altering the data source of a DataWindow (for example from pass through SQL to a Stored Procedure) is difficult if not impossible.
Also, the tight coupling of data access and data presentation makes it difficult to separate the business rules from the user interface. DataWindows cannot contain code and are not object oriented. Thus, they cannot be subclassed to create descendent classes with modified or enhanced characteristics. As such they cannot be used as business objects.

PowerBuilder encourages that business rules be encapsulated in Non Visual Objects (NVOs) in order to separate the business rules from the user interface. The problem with this approach is that PowerBuilder developers implement costly and time consuming code to coerce customizability from the non object oriented DataWindow.

Conclusion: The PowerBuilder approach for separating business rules from the UI is far more complex than the Delphi equivalent. The DataWindow architecture is not extensible, nor is it effective for business logic partitioning, Partitioning client / server applications in PowerBuilder results in code that is difficult to maintain.

Server Response from: ETNASC04