Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Execute Default Behaviour
Message
De
01/04/1998 03:28:45
Steve Camsell
Windmill Associates
Bath, Royaume Uni
 
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00088334
Message ID:
00088616
Vues:
27
Hi David,

>1) "Why don't you want to run the code there?"
>2) Skipping a level to call the ParentClass is generally frowned upon it's a sign functionality hasn't been put where it properly belongs.
>3) The button shouldn't know any of the details about the class tree of the form. The button should only talk to the form object and let the form deal with it's inherited code.

I am curious about why this is a bad design, I thought that my app was structured fairly well (not perfect by a long way, but not bad). The scenario is as follows:

There are three levels to my basic design, the form, a User Interface object (based on a container) and a business object. The UI object sits on the form, the BizObj sits on the UI object. In this particular example, I am dealing with customer addresses for a mail order system. I therefore have a BizObj which knows how to add a new address and delete an address (which it does by calling stored procedures in SQL Server). My UI object contains text boxes for address line 1, 2 etc. The text boxes are based on a view, and when the UI object is created, I tell it what the view is called to try to establish some independance between the two between the UI and the data.

The UI object can also find a record in that view. It contains a generic method, which it inherits from it's parent class, where I pass it the view name, and view key, and it locates that record and does a Refresh() on itself. The UI never dictates which record should be selected, it is told by objects at the form level. In this way I can use my Address UI object and address BizObj for orders, lines, warehouses, contacts, suppliers etc. The form therefore contains a drop-down listbox populated with all the address descriptions from the view. When a row in the list is chosen, the listbox tells the UI what to display.

The problem comes when the user saves changes to an address. This could include a change to the address description, which is what the listbox displays, therefore the listbox has to be Requeried. If the UI object to be generic and independant, it cannot know about the existance of the list box on the form. I therefore just call a THISFORM.Refresh(). In the Refresh() of the form, I update the list box by doing a Requery() etc.

Again, I know that this is not perfect, but I've never tried writing a system in anything like this way before, and this system is too important to the company for me to try something completely new (on top of trying to get to grips with client-server!). Can I therefore just ask (if you've managed to read on this far) what your basic opinion is of this design.
Steve Camsell
Development Consultant
Steve.Camsell@Windmill-DBM.Co.Uk
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform