Clients

Now for the final part of the puzzle. What is the best way for our client applications to use action objects? Basically, the client should open the appropriate action object, retrieve the required recordset, and then close down that action object immediately. When the data is ready to be returned for update, the action object will be instantiated again, the relevant Update method will be called, and then the action object will be closed down again. Here is an example of a client calling an action object to retrieve the list of current employees:

Dim ocaEmployeeMaintenance   As caEmployeeMaintenance Dim ocRecordset              As cRecordset Set ocRecordset = New cRecordset Set ocaEmployeeMaintenance = _     New caEmployeeMaintenance ' Open Employee action object ocRecordset.Serialize = _     caEmployeeMaintenance.GetCurrentEmployees.Serialize Set ocaEmployeeMaintenance = Nothing ' Do stuff with local ocRecordset in user interface ' ... Set ocaEmployeeMaintenance = New caEmployeeMaintenance ocaEmployeeMaintenace.UpdateEmployees ocRecordset Set ocaEmployeeMaintenance = Nothing 

This code could be in a Visual Basic form, in an Active Server Page, or even in an ActiveX document—the important thing is that the client reference to the action object is as quick as possible. The recordset maintains the data locally until the time comes to the send the data back to the action object.

Wrap Up

So there you have it, a workable approach to implementing high-performance distributed objects. With the right amount of planning and design, an awareness of distributed application issues, and the power of Visual Basic, building powerful, scalable software solutions is well within your reach.

So get out there and code those business objects!