Hi Larry,

We're in the initial design stage of moving our logic to business objects, so this is all just theoretical right now.

>What would be the problem of having code in the Init set the data services object for you? The Init could make a call out to a data services manager object that gives it an existing data services object for its use. It then sets its own internal property. The internal property would exist for the life of your method call and it could set the property to NULL in the Destroy.
>

I still don't understand how I would get a reference to the existing object, whether it is the data services object or the data services manager. Could you explain that in a little more detail? Would GetObject() do this for me?

>This raises a question for me. How stateless do you want your objects to be? If you instantiate a COM+ object and don't make any calls to it, the only method to fire in the object is the Init (and any methods the Init calls). The object is active and has state. If in your methods, you have code to call either SetAbort or SetComplete then the object's state goes away. The next time you initiate a call, the object will have to be reinstantiated in the COM+ server.
>

I haven't used COM+ before, but I understand it does some object cacheing and sharing on its own, so maybe I should just let COM+ handle things for me. However, I can still forsee a scenario where I have several business objects instantiated simultaneously, each with their own data services object. This seems like a waste of resources. Maybe that's the way it is supposed to be. To be honest, I am more concerned with designing things the "right way" rather than conserving resources.

Thanks.