|
Session E-DESK
From the Desktop to the Internet
Kevin McNeish
Oak Leaf Enterprises, Inc.
Contents
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!
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:
-
Launch any Microsoft Office application (i.e. Word, Outlook, PowerPoint, Excel)
-
From the Tools menu, select Macro|Visual Basic Editor to launch the Visual Basic Editor
-
From with the Visual Basic Editor’s Tools menu, select References
-
From the References dialog, find “Microsoft Word Object Library” (whichever version you happen to
have) and click the check box next to it.
-
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:
Encapsulation
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
-
Data Integrity Rules (i.e. must-key fields, unique values, field lengths)
-
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:
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
Conclusion
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.
| 
