When you installed Visual FoxPro on your computer, a complete set of samples where copied into the Visual FoxPro install folder. One of these samples is the Tasmanian Traders application. The Tastrade application is an order entry system for a fictional import and export company that sells specialty foods from around the world.
Tasmanian Traders provides order entry functionality, making it possible for users to:
In this section, we will re-create parts of the Tasmanian Traders (Tastrade) sample application, but in an n-Tier architecture to show you how easy and fast is to build the Business Rules layer for a classic application using FoxDataObjects.
You can check the original Tasmanian Traders sample application located on your Visual FoxPro’s Samples folder to get an exact idea of the application.
Before writing any code for Tasmanian Traders, a specification detailing the system requirements, functionality, and appearance must be written, revised, and refined. But in summary, the specification includes the following required elements:
Functionality
The application provides order entry functionality, which must include features that make it possible for users to create new orders; add items to orders directly or select items from previous orders; and calculate line item extensions, subtotals, and order totals adjusted for discounts and freight.
Excluded Functionality
The application will not manage accounts receivable, billing, or inventory.
Architecture Requirements
The application must be able to be deployed in Monolithic, Client-Server or n-Tier sceneries. The Business Rules logic must be separated from the UI code and Data Storage code. It should be able to be configured to store data on native Visual FoxPro database files or remote RDBMS like SqlServer or MySQL.
Interface Requirements
The interface must meet Windows standards. It should be as attractive and intuitive as possible. These subjective interface requirements were difficult to specify in detail. Consequently, they underwent quite a few changes through the development cycle.
FoxDataObjects Features
As a sample, the application must illustrate many of the new features of FoxDataObjects, show how to use FDO in the Business Layer, how to automate Data Storage maintenance and how to integrate the User Interface layer.
System Requirements
The application must run with the minimum processor and memory requirements that Visual FoxPro requires, and in a screen display of 640 x 480 pixels.
To accomplish all of the specified requirements we will use FoxDataObjects ORM features to build the Business Rules layer.
The following tutorials cover all aspects for an n-Tier application development process, from how to begin the project and the basics, through how to use the intermediate and advanced features provided by FDO.
To avoid repetition of similar concepts, the tutorials will show you examples on how to accomplish a representative subset of tasks for such a development process.
The complete Tasmanian Traders sample application is included on the FoxDataObjects’ install folder. You can see the whole solution running, and check all of the fully commented code in both, the Business Rules layer classes, and the UI forms and controls.
The full application sample included in the FoxDataObjects installation folder uses a native Visual FoxPro database to ensure the sample is ready to run right out of the box. The tutorials included in this section use Microsoft SQLServer as development-time data store repository to show you the full potential of FDO when working with remote RDMBS at development time. You can use MSDE, Ms SQL Server, MySQL or any supported data store with just a little change that is fully explained in the corresponding tutorial.
The tutorials assume you have Visual FoxPro (7, 8 or 9) and FoxDataObjects installed on your computer. They will introduce you on how to begin the project, how to define the business objects’ classes, how to use FDO to create a complete relational model for the object model, how to use persistence services to test the classes’ definitions, and how to access the entire Business Rules layer services from the User interface layer.
We will use an exclusive folder in the local hard drive to put the entire project files as instructed in the first tutorial (“Initiating the project”).
As stated in the introduction, FoxDataObjects allows us to begin our application development process right from the object model. Therefore, on these tutorials, we will use a PRG based approach for our business classes definitions, in order to be easy for you to cut and copy the samples code from the tutorials right into your VFP project.
From an Object-Oriented Analysis viewpoint, the central entity on this application is an Order, which is involved in the most relationships. Other entities directly or indirectly support an order:
Two entities, Supplier and Category, support the Product entity although they do not directly supply information for an order. Suppliers are the source of the products while the Category entity provides information that can be used to manage the products. In Tasmanian Traders, these entities are not very significant. In other applications, for example, an inventory management application, they would be.
To show how a complete object orientation helps us with the application design, we will create a generic Person class. Employee entity will inherit from Person. Customer and Provider will be related to a Person instance (as Contact). In addition, all Addresses will be managed as entities to show you how powerful an object model like this becomes.
| Home |
Send feedback on this topic to RunAhead Technologies
For Technical support and product issues please contact us at support@foxdataobjects.com or visit http://www.foxdataobjects.com
Copyright (c) 2000-2005 RunAhead Technologies