The Mere Mortals Framework for Visual FoxPro
Oak Leaf Enterprises
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
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
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?
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.
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
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
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
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
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.