Writing a Visual FoxPro application that stores data in
a RDBMS can be as simple as slapping a few components on a form, defining some
Data Environment objects (tables and cursors) and binding them (as a basic
example). However, if you rely on this tight approach you lose the benefits of
encapsulation and set yourself up for a larger maintenance burden ahead.
Benefits of Business Objects
If you are still writing applications that use data-aware GUI components to
interface directly with the database, you might want to reconsider. Applications
built in this manner are not object oriented. Such two-layer (GUI/Database)
applications violate one of the primary principles of object-oriented design:
encapsulation.
Encapsulation is what allows a client to interact with an object without
knowledge of its implementation details, a primary premise for loose coupling.
In applications that use data-aware widgets, the opposite is the case. The
client and the database are very tightly coupled. GUI code, business logic, and
SQL statements are all interwoven throughout the application source code. As a
result, the application can become a maintenance nightmare. Any changes in the
database schema will surely cascade into unexpected failures.
A much better approach utilizes the business object model. A business object is
modeled after a business or organization concept, such as a person, place,
event, or process. It represents a real-world entity such as an employee,
product, invoice, or payment. Business objects fully encapsulate the behavior
that is expected from the entity they model.
For example, an Item object in an invoicing application can be asked "How much
is available for sale?" or "What is the unit price when 10 units are purchased?"
simply by calling getQtyAvailable() or getUnitPriceForQty(qty) methods in the
object.
Below is a short list of reasons you might want to use business objects in your
next project:
1. Business objects fully insulate clients from business rules, the underlying
data storage, and concurrency issues, resulting in complete encapsulation.
Because clients only interact with business objects, changes can be made in the
database without having to touch a single line of code at the client.
2. Applications have an open architecture and are fully scalable. Business
objects can be implemented in a variety of configurations from client/server to
n-tier.
3. Applications built with business objects are also much more maintainable. The
architecture separates responsibility into loosely coupled layers (i.e., user
interface, business objects, and data storage). Business objects can be loosely
coupled to the user interface using the model-view-controller (MVC)
architecture. MVC is a modular approach to GUI construction that separates the
user interface, control of user input (i.e., event handling), and business
objects into three different components that interact together. Because of this
separation of responsibility, applications can be modified more easily when the
business needs change.
4. Business object models are based on procedures already established by the
organization. Experts in the problem domain who are not necessarily developers
can design the model. Developers can then implement it using any object-oriented
language.
5. Business objects can be implemented as components reusable by different
client applications. Clients can have different user views (GUI interfaces) of
the same object depending on purpose.
6. Thin clients that run on the new network computers (such us the NC or the
NetPC), or run on other devices (such as mobile phones, PDAs, or TV boxes), are
easier to implement. The client needs only to contain user interface code. All
business logic and data storage code resides on other machines across the
network.
The Problem
Object-oriented programming (OOP) has become the dominant programming paradigm
these days.
In OOP languages, a class encapsulates the structure and behavior of
objects of a certain type. Business objects are easier to represent as instances
of these classes.
One common need for virtually all business applications is the persistence
(stable storage) of business objects. The options for persistent storage are
file systems (VFP tables), object-oriented databases and relational SQL
databases (RDBMS). For simple, non-mission critical applications requiring low
data volume, a file system solution may be sufficient.
For high performance,
scalable, transactional and robust applications, a database management system is
required for storing business objects.
Relational database management systems provide a popular and pragmatic
repository for these business objects because of the maturity of the RDBMS
technology and the availability of numerous third-party tools for analyzing and
managing the relational data.
However, there is an inherent conceptual
paradigm-mismatch (also known as impedance mismatch) between an
object-oriented model and a relational model.
Furthermore, SQL as the standard language of interface for relational
databases does not mix well with an OOP language. However, there is a
genuine need to use relational databases to store business objects.
The root of the problem is that objects can't be directly saved to and
retrieved from relational databases.
While objects have
identity, state, and behavior in addition to data, an RDBMS stores data
only. Even data alone can present a problem, since there is often no direct
mapping between Visual FoxPro objects and RDBMS data types.
Furthermore, while objects are traversed using direct references, RDBMS
tables are related via like values in foreign and primary keys.
Additionally, current RDBMS have no parallel to Visual FoxPro’s object
inheritance for data and behavior.
Finally, the goal of relational modeling is to normalize data (i.e.,
eliminate redundant data from tables), whereas the goal of object-oriented
design is to model a business process by creating real-world objects with
data and behavior.
Robust object-oriented application development requires a
mapping strategy built on a solid understanding of the similarities and
differences in these models.
How to bridge this gap?
First need is to easily define
the mapping between the object model and the relational model.
The second
need is to store this mapping information such that it can be used most
naturally and conveniently.
Thirdly, there is need for a product to understand this mapping and do
appropriate translation between the object and relational data. That also
includes the functionality of generating the relational schema definition
given the class definitions and the mapping information.
Finally, there is need for defining an intuitive
application-programming interface (API), which will make the task of a
programmer easier by relieving him of the burden of generating low-level SQL
statements to store/get the object data into/from the relational database.
RunAhead Technologies™ provides an innovative solution, to define the mapping
between an object model and a relational model. We also describe an API that can
effectively be used by all level Visual FoxPro developers to meet their object
persistence needs using an RDBMS. The name of our product is FDO, which stands
for FoxDataObjects™
Why FoxDataObjects as a Solution?
Persistence of business objects using RDBMS is an important requirement for
modern applications that are developed on the Visual FoxPro platform. However,
as seen, there is an inherent paradigm-mismatch between the object model and the
SQL relational model.
FoxDataObjects OR-Mapping technology seamlessly bridges the gap between the two models by
providing a very natural and powerful object oriented interface to store and
retrieve Visual FoxPro business objects.
FoxDataObjects can generate the database schema from
Visual FoxPro object models (class definitions) and vice-versa.
FoxDataObjects leverages
ODBC standard but hides all its complexities and thereby helps achieve
significant reductions in overall time, risk and cost associated with database
applications programming.
FoxDataObjects uses a clean, non-intrusive approach, which does not require your business
objects to inherit from supercharged and limiting base classes, and do not
require any pre-processing or post-processing of Visual FoxPro code at
production runtime.
FoxDataObjects, itself, is implemented in 100% Visual FoxPro code
around a high performance C++ Visual FoxPro Link Library, making it easy to be added
to your existing Visual FoxPro applications.
FoxDataObjects dramatically simplifies development of the data and business
tier of the database application. It provides:
A Persistence Engine that handles all objects
persistence-related tasks transparently. Moreover, this engine allows to
almost forgetting that an underlying database exists - it handles even
database schema updates. This engine completely supports inheritance,
relationships and collections, object queries, full-text indexing, search, and
many other features. Use of this engine makes your data tier automatically
compatible with Microsoft SQL Server 2000, MDSE 2000, MySQL, PostgreSQL,
Firebird, Sybase, DB2 and native VFP databases and tables without any additional code.
(Oracle and Informix support are in beta testing stage at this time
and will be released soon)
A huge reduction on coding time and a significant
overall performance improvement that allows software developers to:
Accelerate development lifecycle by avoiding
tedious, time-consuming and error-prone tasks of low-level ODBC/ADO SQL
programming for persistence of business objects.
Accelerate data movement by using FDO’s fine-tuned
object-relational mapping engine.
Accelerate your Visual FoxPro/ASP projects by
concentrating on business logic instead of wasting time on infrastructure
details.
Methodology that standardizes and simplifies the
development of persistent classes and services operating with them, providing
very clear separation of your business and data tiers from other parts of the
application.
FoxDataObjects works directly with your actual classes and it
does not imposes any class inheritance restriction (like others frameworks do)
giving you total freedom to build the hierarchy of your persistent and
business objects or use your existent classes.
Transactional Services that allows to almost
forgetting that your business and data objects operate in the concurrent
transactional environment.
Transactional services wrap all objects and data
updates into transactions providing that if contention, or data validation
exceptions rollbacks occurs, no data will be changed. Note that this behavior
is provided completely transparently for the developer, but nevertheless it's
highly configurable.
