>> If I understand 3-tier programming methods, the data, business rules, and user are all separated. If I develop a non-visual class that manipulates a few tables, how do/should I access the database. What I mean is should the class include the necessary USE,SELECT,CLOSE commands to manipulate the tables? From what I've seen in Codebook, they've created a data class that you call to do the USE stuff for you, similar to the Data Environment. Is this correct? I guess that's what I'm looking for anyways - a non-visual equivalent of the Data Env.>
>
>You're right. A three-tier architecture looks like this:
>
>Tier 1: User Interface, Application logic
>Tier 2: Business objects / rules
>Tier 3: Data
>
>In order to maintain the separation between the tiers, you want all data manipulation to occur through the business object.
>
>In Codebook, a business object contains a DELoader object which is responsible for loading/unloading the cursor(s) associated with the business object. Once a cursor has been loaded, any user interface control on the form can directly reference the cursor's fields in its ControlSource property.
>
>However, the business object is responsible for handling all data manipulation such as adding, saving, deleting and navigating through records in its associated cursor.
>
>> After looking at the example program in the Codebook 3.0 book, I'm a little confused as to how "separate" the business class and the "User"/Interface actually are. It looks like they almost overlap quite a bit. Shouldn't your forms almost exclusively call Methods in your business objects (I wish I had Codebook in front of me...)? I'm not sure if this is even possible, given how much interaction is sometimes necessary between your forms and your "business logic".
>
>In the sample application that comes with VFP3, there is actually a bit too much overlapping of Tier1 and Tier2. This is because the user interface controls are contained within a business object. User interface controls should be added to forms outside the confines of the business object container. This accomplishes two things:
>
>1. It makes the business object far more reusable. When you tie user interface controls to a business object it makes it impossible to reuse on another form.
>
>2. It makes it much easier to scale up to a true three-tier architecture where business objects physically reside on another computer.
>
>If you have any further questions, please let me know. It's hard to explain the whole architecture in a single e-mail. We provide training for our Codebook for Mere Mortals framework and I spend half a day explaining three-tier architectures, data environments and business objects!
>
>Regards,


If the business rules are running on a server someplace, how do we get the data from there to the UI part? Say we pull several records in a query (view, etc)..
the business object talks to the data...how do we transfer that data from one machine to another?