>Ok, so the "fourth tier" is the physical data? I realize that's not actually >the case, but there is a kind of separation there.

The middle tier is the one that gets carved up into separate layers... UI Objects, Business Rule Objects, etc...
>
>So, would you typically have all the data access go through one class, that >talks the all the tables, or would you have subclasses for each table?

I would set up classes that related to real things. If it turned out to be a 1 to 1 correspondence between classes and tables - fine. But, that may not always be the case.

>One other thing I've been confused on: in a current project I'd like to model, >we have an order table, an order line table, a payment table, and a payment >line table. The payment line table refers to the invoice/order. That's four >classes as well, right? with Orders and Payments having collection Properties >containing line items?

It may be four classes...it may not be. It depends on the entire context of teh application. For example, anytime I would never work with order line items outside the context of orders. That said, I would probably make use of ADO Hierarchical Recordsets and have an orders class - that takes care of creating and returning the recordset. Payments are a bit different. You can look at payments independent or orders. And, you can look at payments in the context of an order. Clearly - there is a paymements class. The question is how can it be instanced. One way is directly - to see 1 or more payments - parameterized by either customer number and/or order number. Another way is via a method in the Orders Class - lets called it oPayments. The Access Method would actually instance the payments class - that in turn - would create the payments/payment line items hierarchical recordset.

As far as business rules go, you could have two classes here - one for orders and one for payments. Before updating the database ,you would pass the respective recordset to it's business rule object. It it passes - you update. Otherwise, you don't.

Using ADO as your data object will prove to be much faster than fabricating collections and the like with VFP custom classes.

Just food for thought...