Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Alias Not Found
Message
De
11/01/2000 17:18:39
 
Information générale
Forum:
Visual FoxPro
Catégorie:
The Mere Mortals Framework
Titre:
Divers
Thread ID:
00315735
Message ID:
00316523
Vues:
19
>If messages are placed in the business objects then the ojbects become tied to specific types of interfaces. (VFP messages are not compatible with VB.)
>
>What we do is have the UI display messages that indicate something is happening before a business object's method is actually called. Then if the called method indicates that something went wrong the UI is designed to ask the business object exactly what happened and the UI is free to diplay this information. Kevin has recently added and error array to the kBizObj so error codes or messages can be stored there for later query by any UI.
>
>To make a long story short. The idea is that the interface handles EVERY aspect of communicating with the end user. The business object simply records its errors in the aErrorMsg array using the AddError() method. If you do anything else the business objects start to loose the ability to be reused by different front ends that are developed in different languages.
>
>lRetVal = BizObj.Method()
>If lRetVal = .F.
>For lnCount to Alen(BizObj.aErrorMsg,1)
> MsgSvc(BizObj.aErrorMsg[lnCount])
>EndFor
>
>I hope this helps.

Thanks, William. Actually it does help. I wasn't aware of the ErrorMsg array, and I had suspected that the way to handle messages was in the UI itself. I'll need to adjust my programming practices a bit to truly separate my bizobj from the UI to make them completely COM ready.

Although this makes my objects more portable, many of my applications don't need this level of abstraction because most of my business objects will never be compiled into COM objects. Nonetheless, it would be prudent to create business objects as if they were going to be compiled into COM objects for a multitude of reasons: others may want to tap into my data from a different UI; solid object-oriented programming suggests that specific functionality be encapsulated in separate objects; etc. Forgive me if I seem to be rambling on about mundane issues, but writing down my thoughts helps me to understand the concept better, and other users may benefit from my thoughts.

Thanks again.
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform