Session E-DESK

From the Desktop to the Internet

Kevin McNeish
Oak Leaf Enterprises, Inc.


Most developers I talk to these days realize that they eventually need to access all or part of their Visual FoxPro desktop applications via the Internet. However, it’s one thing to create an application that runs only on the desktop or only on the Internet—it’s quite another thing to create a desktop application that can scale to the Internet. What pitfalls do you need to avoid and what proactive steps do you need to take in order to make it a smooth transition rather than a complete rewrite? This white paper presents this information in the context of Visual FoxPro

There are two main types of Internet applications—thin client and fat client. Although you can create fat client applications that take advantage of the Internet, to ensure the greatest scalability, this paper focuses on creating desktop applications that can be accessed from a thin client HTML front end. If you aim for thin client your application will still work well as a fat client!

Building Monolithic VFP Applications

Many Visual FoxPro developers create monolithic applications that have the user interface, business and data access logic inextricably bound to each other. This is the way that FoxPro 2.x applications were created and it’s very easy to continue programming the same way in Visual FoxPro.

The problem with this approach is that your application is a rock in the river of change! Each time either the user interface, business or data access logic changes you must recompile your application and redistribute it. This model is very expensive to both create and maintain. In addition, it severely limits the application’s scalability. When you need to move to a two-tier model (client/server) or a three tier model it requires a rewrite of the application.

Creating Three-Tier VFP Applications

In order for a desktop application to scale to a thin client Internet application, it must be partitioned into three different tiers—the presentation tier, business tier and data tier. However, this is often easier said than done. It is more difficult to create an application that adheres to the three-tier architecture. It also requires a different set of analysis and design skills than those that work well for a monolithic software application. However, if you need to create an application that scales from the desktop to the Internet, not only is it well worth the effort, but it’s imperative!

Placing Business Logic in the User Interface

Many developers make the mistake of putting the majority of their business logic in methods of the user interface—whether it be form methods, Click, Valid or InteractiveChange methods of user interface controls. Although this works great for a desktop application, what happens when you replace your Visual FoxPro user interface with an HTML interface? When you remove the Visual FoxPro interface, your application logic goes with it!

  Textfeld: Note: 	As you’re typing code in a user interface method repeat the following phrase to yourself: “I will not be able to access this code from the Internet”, “I will not be able to access this code from the Internet” <s>.


Place Business Logic in Business Objects Instead

Rather than placing application logic in the user interface, you should place it in business objects. A business object is a high-level abstract object that represents a person, place, event or business process. All applications have certain entities that are the main “things” handled by the application. For example, if you are creating a point-of-sale application, the main business objects might be Customers, Invoices and Inventory. You can create classes that represent each of these entities!

A good example of business objects at work are Microsoft Office applications. Try the following:

  1. Launch any Microsoft Office application (i.e. Word, Outlook, PowerPoint, Excel)

  2.  From the Tools menu, select Macro|Visual Basic Editor to launch the Visual Basic Editor

  3. From with the Visual Basic Editor’s Tools menu, select References

  4.  From the References dialog, find “Microsoft Word Object Library” (whichever version you happen to have) and click the check box next to it.

  5.  Click the OK button to close the References dialog.


Next, from the View menu, select Object Browser. In the combo box at the top of the Object Browser dialog, select Word. In the bottom half of the Object Browser you will see a list of all public classes (business objects) found in the Microsoft Word Automation server. Click on some of the classes (for example, the “Document” class) and you will see a list of PEMs for the selected class in the Members pane on the right.

For more detailed information on business objects, see the following articles in FoxPro Advisor magazine:

Visual FoxPro Business Objects – July 1999 FoxPro Advisor
Create Business Objects—Then Put Them To Work! – December 1999 FoxPro Advisor

Business Objects in Automation Servers

Creating business object classes is the hard part—making them accessible from a wide variety of tools is very easy. By simply marking your business object classes as OLE Public you can then compile an Automation Server from which your objects can be accessed from a wide variety of tools—including Active Server Pages! This is one of the ways you can access your application via the Internet.

Benefits of Using Business Objects

In addition to scalability, there are a number of other great reasons to place your application logic into business objects:


Procedural software programs usually have related logic scattered to the four corners of the application—into procedures, functions, form and control methods.

In contrast, business objects allow you to encapsulate all of the characteristics and behavior of a real-world entity, such as an Invoice, into a single object. You can place all of the application logic that applies to that entity, including the data manipulation logic, into a single object.

This is extremely useful for solving the “Where’s the code?” syndrome. When you don’t use business objects it can be very difficult to find the code you’re looking for—especially a few months after it’s been written. Often, the code is buried deep within the method of a user interface control. However, if you store your application logic in business objects, it’s very easy to find the Invoicing code that isn’t working properly—it’s in the Invoice object!

Normalizing Application Logic

In most any software program, you’ll find application logic that is duplicated throughout the application. This is especially true if you have multiple developers working on a project. The same logic can be repeated two, three, four or more times!

However, when you place your application logic in business objects, it is rare to duplicate the same piece of logic. For example, once you’ve added a “CalcInvoiceTotal” method to an Invoice object, there’s little chance that you’ll add that same method a second time.

Business objects make complex software systems easier to understand and create because they closely model real-world entities. There is a one-to-one correspondence between objects in the real world and objects within your software application.

Although this concept may be difficult for procedural programmers to grasp, once you understand it you’ll never want to go back! Business object encapsulation makes the job of analysis, design, software construction and maintenance far easier than procedural techniques.

Bridging the Semantic Gap

In a procedural software application, there exists a “semantic gap” between the real world and your application. This gap is caused by the lack of a one-to-one correspondence between the real world and your software. If you open the hood of your program you won’t find an Invoice—you might find an Invoice form, an Invoice report or logic that applies to the concept of Invoicing, but there is no single object that represents the real world Invoice entity—this is the semantic gap.

In object-oriented software, business objects bridge the semantic gap by providing a one-to-one correspondence between the real world and your software application. Because of this it is far easier to conceive, design, create and maintain applications that use business objects.

Tip: Create Business Objects First

Even developers that understand the concept of separating applications into three tiers often find themselves placing user business logic into the user interface.

To avoid this problem create your business objects first, before creating your user interface. You can then instantiate and test your business objects from the Visual FoxPro Command Window. If there’s no user interface in sight you won’t be tempted to enter your business logic into it!

User Interface Logic in Business Objects

Not only is it easy to make the mistake of placing business logic in the user interface, it’s also very easy to place user interface logic in business objects! Business objects should not contain any code that interacts with the user interface such as displaying messages or referencing user interface controls.

Placing user interface logic in business objects is a real problem. First of all, business objects instantiated on web servers should not display messages. It won’t do your web clients any good to have your web server displaying messages! In addition, business objects compiled in an in-process (dll) Automation Server generate errors when interacting with the user interface.

To prevent this problem, again you can test your objects from the Visual FoxPro Command Window—if they display any messages you’ve got a problem! In addition, you can use a tool such as the VCX Editor that accompanies this white paper to search for user interface references in business object classes (See the section The VCX Editor at the end of this paper).

Putting Business Rules in the Right Places

In a three-tier architecture, business rules can be placed in any tier, but they are often not put in all the right places.

Business rules fall into two broad categories

  1. Data Integrity Rules (i.e. must-key fields, unique values, field lengths)

  1. Domain Rules (i.e. “Customers over their credit limit cannot generate new invoices”)

Business Rules in the User Interface

Many Visual FoxPro developers place data integrity rules in the user interface by means of application logic, user interface InputMask and Format properties. However, when the Visual FoxPro user interface goes away and is replaced with an HTML interface, again, the business rules go away too!

Business Rules in Business Objects

To solve this particular problem, business rules should also be enforced in business objects. That way, wherever the business objects go (they’re always there!) the business rules go with them. Notice the first sentence in this paragraph says “also”. If you completely remove business rules from InputMasks and Format properties you will end up with a user interface that will make your users very unhappy. For example, if the user interface lets them enter a 30 character last name, but they don’t find out until they try to save a record that they’ve entered too many characters, you can be guaranteed that they won’t be pleased!

Business Rules in the Data Tier

To solve this particular problem, business rules should also be enforced in business objects. That way, wherever the business objects go (they’re always there!) the business rules go with them. Notice the first sentence in this paragraph says “also”. If you completely remove business rules from InputMasks and Format properties you will end up with a user interface that will make your users very unhappy. For example, if the user interface lets them enter a 30 character last name, but they don’t find out until they try to save a record that they’ve entered too many characters, you can be guaranteed that they won’t be pleased!

Business Rules in the Data Tier

If you only place your data integrity rules in the user interface and in your business tier it still presents a problem—what happens if someone accesses your data directly without going through the business tier (stranger things have happened <s>). This highlights the importance of placing business rules in your data tier. It’s truly your last line of defense.

Data Access Logic

Many developers place logic in the user interface that loads, accesses and manipulates data. This includes use of the data environments built into forms and reports. When data access logic is in the user interface it presents the following problems:

  • It bypasses the business tier including business rules for data validation!

  • It kills scalability—many Internet applications scale to client server data such as SQL Server and Oracle. If your user interface has direct access to your back end data, if the back end changes so must your user interface!

  • It exposes the user interface to the structure of the data. When the data structure changes, so must the user interface.

To solve these problems, all data manipulation should take place through business objects. This includes both loading and manipulating data. In addition, their should be a thin data layer on the business object that is responsible for the “rubber meets the road” data access. This prevents the business object from having to constantly change whenever the back end data changes.

Serving Up Data in a Variety of Formats

Business objects should be designed to serve up data in a variety of formats. Depending on the type of client that is accessing the business object one data format is usually preferable to another. For example, a web page might need data in XML, HTML or ADO formats. The data format best suited to a Visual FoxPro user interface is usually a Visual FoxPro cursor.Rather than forcing a particular data format on a client, create business objects that can server up a variety of data formats.

The VCX Editor

To use the VCX Editor, from within Visual FoxPro, CD to the folder that contains the VCX Editor files (or just set a path to the folder). To launch the editor, from the Visual FoxPro Command Window enter: DO FORM VCXEDIT.


To open a VCX File, click the Open button and select the class library to be edited from the Open dialog. You can use the VCR navigation buttons to move between records. If you’re searching for a particular record, you can click the Find button and enter search criteria to locate the specific record. The VCX Editor buffers your VCX file so you can make changes to multiple records then cancel changes without permanently saving them to the VCX. You can also select many of the fields visually which saves you from typos!

Searching for User Interface Logic in Business Objects

To search for user interface logic in your business object classes, open the business object library in the VCX Editor (this assumes you have not placed user interface controls in the same library as your business objects!). Click the Find button and in the Find dialog, select “Methods” in the Search combo box. Next, enter a user interface reference such as “thisform” or “messagebox” in the For box, then click Search. If the VCX Editor finds any UI references you can easily fix these from within the Editor itself or by editing the class in Visual  FoxPro’s Class Designer.

Note: The VCX Editor is a public domain tool that is the copyright of Oak Leaf Enterprises, Inc


There are a variety of tools you can choose to access your Visual FoxPro applications from the Internet. Such as Active Server Pages, West Wind Web Connection and Active FoxPro Pages. Which tool you use is up to you. Talk to other developers who have gone these routes and see what the pluses and minuses are for each. However, the point of this discussion is that you have a choice—by logically dividing your application logic into three tiers you have the option of using one or all of these choices.

vorheriger Vortrag D-DNA2

zur Übersicht der Gruppe WEB

nächster Vortrag E-XML



Frankfurter Str. 21 b


D-61476 Kronberg

per Fax an:


oder per e-Mail an:

© Texte, Grafiken und Inhalt: ISYS GmbH