Using Properties in the Client Application

Within a procedure, you shouldn't make more than one call to a particular property. Each time you call a property, there is overhead, which can result in a massive performance hit on your application. This code snippet shows how not to use a property:

Dim oEmps as Employees Set oEmps = New Employees

If oEmps.EmployeeNo <> sExcludedEmpNo Then TxtEmpNo.Text = oEmps.EmployeeNo Call BuildSomeCombo(oEmps.EmployeeNo) MsgBox "Found Employee No" & oEmps.EmployeeNo End If

Set oEmps = Nothing

In this simple example, there are four calls to the EmployeeNo property. That's four times the client application has to navigate to the Property Get procedure, and four times the Property Get procedure has to execute. You can optimize this code by accessing the property once and storing its value in a local variable, as the following code fragment illustrates:

Dim oEmps as Employees Dim sEmpNo as String Set oEmps = New Employees sEmpsNo = oEmps.EmployeeNo Set oEmps = Nothing

If sEmpNo <> sExcludedEmpNo Then TxtEmpNo.Text = sEmpNo Call BuildSomeCombo(sEmpNo) MsgBox "Found Employee No" & sEmpNo End If






You may have noticed another important benefit we've managed to gain in the reworked code. The object reference is destroyed at a much earlier stage, which means that the object is used only for a short period of time. This is a major consideration as far as scalability is concerned when designing large client-server applications.

Was this article helpful?

0 0

Post a comment