9.3 Better than sliced bread: sliced applications

Better than sliced bread: sliced applications

Conceptually, the idea of three-tiered development is simple: You take your regular applications and slice them in three layers. Interface elements belong in the interface layer. Business rules, logic, and data validation belong in the middle tier, and the data store is in the data layer. While this sounds easy, it's a significant change of view for the "traditional" FoxPro developer. Because we have always had data controls that are "intimate" with the data, we have always been able to design interfaces that directly access data in our tables and, with the VALID clause, do validation in the interface. The "one-tier" model (or one and a half if you want to argue about editing memory variables instead of the table) was the natural way to go and, with FoxPro, worked quite well.

Well, Visual FoxPro is now playing in a larger arena and, if you want to structure applications to play the new game, you are going to have to move away from the old ways of doing things. You cannot put your logic into the Valid event of a field in a form. Neither can you directly bind fields to data. You can't even have these parts in the same composite object. Fortunately, all this complies with most of the principles of proper object-oriented design. Rather than using a part of the interface to validate entries, you would call out to a behavioral object. Data would be bound to the interface through well-defined object interfaces. The actual implementation can vary greatly, depending on whether you create COM components or a monolithic Visual FoxPro application (see below).

The most difficult part of three-tiered development is following the rule of keeping the three tiers separate. The interface and business logic components are especially hard to separate. It's tempting to add some code to one of the controls in a form rather than creating another method in a behavioral object that does all the calculations. Unfortunately, as soon as you take such a shortcut, you break your entire three-tiered model. This will set you back to the prior level of software development. Self-control (if you are developing an application by yourself) and code reviews (in team development scenarios) are key. In most areas of development, you can get away with bending the rules every now and then. This is not true for three-tiered architecture. Bend the rules once and you'll lose all the advantages but still carry all the burdens.