Printing - FoxTalk - dFPUG-Portal

usiness rules because they aren't buried in either the front or the back end. If you coded all of
your data validation rules in Visual FoxPro, then it would be difficult to reuse them in, say, a
Visual Basic or Access application. If they were sitting in their own layer, then any front end
could use them to send data to any back end.
This is the general idea of two- and three-tier architectures. In practice, you have more flexibility
in how you structure your applications if you're using Visual FoxPro to build a client/server
architecture. In a two-tier architecture, you can enforce the rules entirely in the back end, entirely
in Visual FoxPro, or in both places. For example, if a rule is that prices can't go up by more than
20 percent, you can do this in SQL Server with a rule or constraint. You can do this in Visual
FoxPro in the Valid event of a text box.
This is a pretty simple rule to enforce. If you enforce it in Visual FoxPro, the user gets instant
feedback and the back end doesn't have to spend time checking the price. If you have 100 users
entering 200 orders a day each, this adds up to a lot of work the back end doesn't have to do. If
the only front end accessing the back end data is your Visual FoxPro application, then you might
wind up putting the bulk, maybe even all, of the data validation code into the front end.
But what if other front ends need to access the data? If Access and Visual Basic applications can
enter or edit orders, then you would want to validate price on the back end. As a wise person
once said, "Write once, use many." If the only other applications to access the data were written
in Visual FoxPro, you could write FoxPro code and share it, perhaps through a stored procedure
or a data validation class.
In a three-tier architecture, you can still split the work by enforcing data integrity in the front
end. If the middle tier is the only one responsible for making sure that price increases are
acceptable, then are you overly burdening that layer? What will you gain by either duplicating or
moving the rule enforcement into Visual FoxPro on the front end?
What is the middle layer written in? The Visual Basic team wants you to write the middle layer
in Visual Basic, using VB 4.0's new ability to create OLE servers. The OLE server could be
called from Visual FoxPro using OLE Automation. Data would be passed to the middle layer,
which would validate it. If the data were rejected, the middle layer would let FoxPro know about
it. If the data were good, it would be sent on to the back end and FoxPro would be told.
You would use this VB middle layer from Visual FoxPro the same way you use any OLE
Automation server. You might issue the following to start a conversation with the server:
oData = CreateObject("VBServer.BizRules")
When you wanted to send data to the middle layer, you might issue the following code:
oData.Send("Update employee Set salary = 87000000")