Visual Basic —

Action Object Interface

We can imagine that a Visual Basic form that implements this usage scenario would present two major pieces of information: EmployeeDetails and Activities. We can now determine the interface of the required action object.

  • GetEmployeeDetails
  • UpdateEmployeeDetails
  • GetCurrentActivities
  • UpdateCurrentActivities

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.