Notice that these attributes of the action object are all stateless. That is, when you retrieve a recordset from GetEmployeeDetails, you then shut down the action object immediately, thereby minimizing the cross-layer communication cost. Users can then modify the resulting recordset and, when they are ready to send it back for updating, you create the action object again and call the UpdateEmployeeDetails method. The action object does not need to be held open while the recordset is being modified. Let's look at these calls in more detail:
Public Function GetEmployeeDetails(Optional i_sID As String) As cRecordset Dim ocfEmployees As New cfEmployees Dim oParams As New cParams If Not IsMissing(i_sID) Then oParams.Add "ID", i_sID ocfEmployees.Create oPicDAL ocfEmployees.Populate oParams Set GetEmployeeDetails = ocfEmployees.Recordset End Function
Likewise, the UpdateEmployeeDetail call looks like this:
Public Sub UpdateEmployeeDetail(i_ocRecordset As cRecordset) Dim ocfEmployees As New cfEmployees Dim ocRecordset As New cRecordset Set ocRecordset = New cRecordset ocRecordset.Serialize = i_ocRecordset.Serialize ' Create local ' copy of object so that business objects do ' not have to refer across network. ocfEmployees.Create oPicDAL Set ocfEmployees.Recordset = ocRecordset ocfEmployees.Persist i_ocRecordset.Serialize = ocRecordset.Serialize ' Copy updated ' recordset back to client. End Sub
The GetCurrentActivities call has a bit more work to do. It must create a new recordset because the usage scenario requires that both Roles and Projects come back as one set of data. So the GetCurrentActivities call would create a recordset with three fields-ActivityID, ActivityValue, and ActivityType (Roles or Projects) and then populate this recordset from the Roles business object and the Projects business object. This recordset would then be returned to the client.
The UpdateCurrentActivities call would have to do the reverse-unpack the recordset and then apply updates to the Roles and Projects table.