The Mere Mortals Framework for Visual FoxPro

The Mere Mortals Framework Enable You To…

• Build applications that run fast!
  
• Create applications quickly
  
• Create solid applications
  
• Create well-designed object-oriented applications
  
• Build flexible applications that anticipate change
  
• Easily change the Framework to suit your needs
  
• Create applications with your own look and feel

Understanding and Using 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 objects 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.

The Mere Mortals Framework allows you to create classes that represent each of these entities. The Framework gives you a jump start on this process by providing a business object class, KBizObj, that serves as a template for your application's business objects.
The use of business objects is not unique to the Visual FoxPro community. These powerful objects have been in use for some time in languages such as SmallTalk, C++ and so on. For more information on the use of business objects outside of the Visual FoxPro world, and for a bigger view of the OOP community in general, check out the Object Management Group's web site at www.omg.org.

Why Use Business Objects?

Encapsulation

Business objects allow you to encapsulate all of the characteristics and behavior of a real-world entity, such as an Invoice, in one class rather than spreading its functionality throughout your application's forms and control methods. 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.

Software Reusability

One of the greatest benefits of using business object is reusability. When you place code in the method of a form, you can only access the method from within that form. For example, if you have an Invoice form in your application, you can add a CheckCreditLimit() method to the form that can be used to check a customer's credit limit. However, this method is only available when the Invoice form is instantiated.

In contrast, if you put the same method in a business object, as shown below, you can drop the business object on any form and have full access to all of its functionality:

Reusing Business Objects in Multiple Applications

Although software reuse within a single application is a good thing, it doesn't stop there. Business objects allow your application's logic to be reused in many different applications! This is possible because you can compile your business objects into Active-X Automation servers that can be accessed by any product that knows how to talk to COM (i.e. Visual Basic, Microsoft Office products).

In order to understand how this works, we need to discuss and define multiple tier architectures. We'll look at single, two, three and n-Tier architectures and see how business objects fit into each model.

Business Objects in Single-Tier Architectures

A single-tier architecture consists of a program running on a user's machine that accesses a database on the same machine or a mapped network drive. All of the processing takes place on a single machine-the user interface, business and data processing.

This architecture encompasses the way most Visual FoxPro applications are configured…a Visual FoxPro executable runs on a workstation(s) and accesses Visual FoxPro data on a local or network drive.

In this model, software applications contain the user interface, business processing and data processing. Business objects are instantiated and run within the application.

Business Objects in a Two-Tier Client/Server Model

In a two-tier client-server model, the work (and associated processing overhead) of storing and retrieving data is moved off of the workstation onto a dedicated database server. This is distributed computing in its simplest form.

This architecture exists in systems where a VFP application is running on a workstation(s) and is accessing a client-server database such as Oracle or SQL Server that is running on a database server.

In this model, the software application still contains the user interface, business processing and data processing. Business objects are instantiated and run within the application.

Business Objects in a Three-Tier Client/Server Model

Three-tier client-server helps ease network traffic by placing an application server-another physical server that manages network traffic-between the workstations and the database server.

This model allows us a great deal of flexibility in deciding where to place the application's business processing. You can move virtually all of the busines processing off the workstations and onto the application server-or leave the majority of the business processing on the workstation.

When your business objects are compiled as Active-X automation servers, you can create a three-tier system architecture in which the business objects are instantiated on an application server via Microsoft's COM (Component Object Model). This is where the multi-application reuse of business objects comes into play.

In a three-tier architecture, the user interface or presentation layer resides on tier 1. This can be a Visual FoxPro program, a Visual Basic program, a Microsoft Office product or any software that knows how to talk to COM objects.

Tier 2 contains your application's business objects which in turn contain the majority of your application logic. This is the key to providing software reuse across multiple software applications.

Tier 3 is where your application's data resides. It may be Visual FoxPro, SQL Server, Oracle, or any database that has an ODBC driver.

In this type of design, any component can be swapped out in an architecture that is far more flexible, extensible and maintainable.

Placing Your Application Logic in Business Objects

What we have discussed so far brings us to a very important conclusion:

Rule of Thumb: The majority of an application's logic should be placed within business objects.

One of the biggest mistakes developers make is placing the majority of their application logic within the user interface. This presents a real problem when you try to move your application to a true, three-tier architecture. It means you will have to extricate the code from the user interface and place it into business objects before it can be reused by other applications.

However, if you start out with this rule of thumb in mind when you begin your project, you can easily create an application that is far more flexible, extensible and reusable…without a great deal of additional effort.

The Problem with VFP COM Objects

The advent of OLE Automation Servers in Visual FoxPro 5 made it possible to create distributed, three-tier applications in Visual FoxPro. Unfortunately, this technology was not-ready-for-prime-time. Unfortunately, although the September release of Visual FoxPro 6.0 addressed many of the difficulties found in VFP5, there is still one major stumbling block that prevents COM objects from being a viable alternative in VFP6.

COM objects created with VFP6 have a problem with concurrency. VFP6 COM objects can only handle a single request at a time. This means that if a particular method in a COM object takes 5 minutes to complete, the next user trying to access the COM object must wait 5 minutes before their request is processed. This limitation makes COM objects virtually unusable except in rare exceptions where you only have a few users trying to access your COM objects in tier 2.

Fortunately, Microsoft is aware of this problem and plans to fix it in an upcoming VFP service pack release. When this version is released, we will provide much information in the pages of this Developer's Guide to help you build highly optimized COM objects that work well with a variety of tier 1 applications.

Logical Three-Tier System Architecture

Although Visual FoxPro may not be ready for COM today, using business objects and creating logical partitions in your applications now will make the step to true three-tier architecture much easier. As shown below, the Mere Mortals Framework allows you to create a logical three-tier architecture.

Within the Mere Mortals Framework, business objects can exist as a second tier within the application. This maintains a degree of separation between each respective tier. Business objects provide a buffer zone between your application and the data. They are responsible for loading, unloading and manipulating data. This allows you to change your application's data source in tier 3 without changing the application code!

If you faithfully adhere to the above model when writing your applications, and maintain the separation between each tier, you can easily move your Mere Mortals business objects out of tier 1 and into a physically separate tier 2 when Visual FoxPro is ready in the near future.