Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Objects in a middle-tier environment
Message
From
10/01/2003 03:56:28
 
 
To
09/01/2003 13:32:58
Joel Leach
Memorial Business Systems, Inc.
Tennessee, United States
General information
Forum:
Visual FoxPro
Category:
Object Oriented Programming
Miscellaneous
Thread ID:
00739857
Message ID:
00740195
Views:
29
Joel

The reason I prefer to reference the object, rather than create, is because all object's are children of the middle-tier application object, the reason for this is because the app object needs to reference objects in their current state (ie the current client's details) so if one object needs something from another, it references the app object to request the info from another object, for the current client record, for example.

It seems to be easier to let this app object do the object creating, so that it can hold the object for future reference, if I create a new instance of the object, it will effectively be an orphan not connected to the (middle-tier) app object.

Does that make sense?

Thanks
Kev
>>Hi
>>
>>I have a complex application that I'm working on splitting up a bit, I'm a little way through but wanted to ask a question. My middle-tier has around 25 data-objects so far, all linked to a main application object.
>>
>>Now, what I want to know is if what I'm doing, is a good idea. Rather than create new instances of data-objects on the forms, I call a method in the (middle-tier) application object that returns a reference to the data-object, this way, if the object is updated by one form, it will always be reflected because it is a continuously running single instance.
>>
>>Is this good practice? Or is it better to create objects freshly?
>>
>
>Hi Kevin,
>
>My opinion is that each form should have its own instance of the data object. The first reason is that most of my forms use private datasessions so that forms using the same data do not interfere with each other. Of course, there are cases where one form opens up another form in the same datasession. In that case, you could pass the data object as a parameter if needed:
>
Do MyChildForm with Thisform.oMyDataObject
>
>The second reason is along the same line of thought that public variables are bad. An application object can certainly provide valuable functions and values to the entire application, but I don't think code outside of the app. object should be allowed to make changes to properties on the app. object. I would be difficult to know whether or not another piece code made changes that you weren't expecting, and even harder to debug.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform