Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Baby Steps!
Message
De
30/05/2002 10:20:06
 
Information générale
Forum:
Visual FoxPro
Catégorie:
The Mere Mortals Framework
Titre:
Divers
Thread ID:
00662635
Message ID:
00662989
Vues:
19
>I know what I want to do but am so set in my old way of thinking it's hard to transform quickly. I will get it though.

Hi Julie. It takes a little while to get your brain trained to MM and OOP. I struggled just as you are, but the payoff for me has been well worth the effort.

This is how we look a things now. We have to have a place to save and retrieve data, so we need databases with tables. We need a way to get at the data, so we need business objects. And we need a way to present the data, VFP forms, ASP ....

Your business objects should be VERY specific in what they do. If we need to act on the customer table, we create a local view on that table, then we create a customerobj based on our abizobj(a subclass of kbizobj). Then we create a dataenvironment using the bizobj builder and add the view to the DE. Now you can add you own methods to your bizobj, if needed, to manipulate the customer data. The customerbizobj acts on the customer table ONLY and ONLY through the view. It knows nothing about the orders table, employee table .... The only other tables that we sometimes add to the DE are lookup tables (tables with info that we are not manipulating, just looking up data). Just remember, if you need to manipulate data in a table, you need a bizobj to do it. If you need to manipulate data in two related tables, you still need a bizobj for each table. Then you can create a parent-child relationship between the objects.

The reason for acting on a view instead of a table is that you can easily replace the local view with a remote view and tie into a different backend (SQL,VFP on a remote PC,...)

One more important tip that Kevin preaches.:) Forget about the user interface in the beginning. Create all your bizobj's in the command window by doing SETX and then creating them with CREATEOBJECT(). Test your methods from there before you ever drop them on a form.

This is exactly the opposite to what I was used to. I would create a form and drop tables into the form DE. Then drop controls on the form and bind them to the fields. But now, it just seems natural to create the objects first.

Hope this helps a little. There are some great people here that use the framework and will be glad to help you along (They have and still do me!)
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform