Visual Basic 6 Business Objects

• facebook
• twitter
• google+
• in
• Email

The use of an object manager makes the process of retrieving, saving, and deleting an object pretty straightforward. However, compared to having an object save itself, this is a bit more complex from the UI developer's viewpoint. The UI developer not only needs to understand how to create and use the business objects themselves, but they need to understand how to create and use the objects that manage the persistence. This seems like extra work for little gain.

On the other hand, it's a small step from having the UI developer call the persistence manager object, as we've just seen, to having the business object itself call the persistence manager object:

This figure indicates that the presentation tier, or UI, only needs to interact with our UI-centric business objects. The UI developer just uses simple Load and ApplyEdit methods on the UI-centric business object, and lets the UI-centric business object take care of asking the data-centric object to actually retrieve, save, or delete the data. The UI developer doesn't have to worry about any of the code to persist the object. At the same time, we get the benefit of having the persistence code in a separate object that can be distributed across the network.

Let's look at how we can modify the previous example to use this new and improved technique. Fortunately, the changes aren't too difficult, so this will go quickly.

Simplifying the Code in the Form

First, let's look at the UI code. The whole idea is to simplify it, and we can easily do that. In fact, we can return it to the form it was in earlier in the chapter, before we implemented the PersonManager. The Apply and OK button code needs to be changed to appear as follows:

Private Sub cmdApply_Click()
objPerson.ApplyEdit
objPerson.BeginEdit
End Sub

Private Sub cmdOK_Click()
objPerson.ApplyEdit
Unload Me
End Sub

We also have code in the Form_Load routine to get an SSN value from the user and to load our Person object using the PersonManager object. We'll need to simplify that code as well:

Private Sub Form_Load()
Dim strSSN As String
Set objPerson = New Person
strSSN = InputBox$("Enter the SSN")
objPerson.Load(strSSN)
flgLoading = True

In all three routines, the big difference is that our form's code doesn't need to create or deal with a PersonManager object. All the UI developer needs to be concerned with are the basic methods provided by the UI-centric business object, which is our Person object.

Since we no longer need to use the PersonServer project from the PersonDemo UI project, we need to use the Project-References menu option and remove the reference to the PersonServer project.

Adding a Load Method to Person

The changes to the Person object itself are a bit more extensive. Earlier in the chapter, we discussed having business objects save themselves to the database. To do this, we created a Load method for the object and enhanced the ApplyEdit method. Basically, we want to do the same thing here, except that the actual database code will be in a separate object, PersonManager.

First, let's add a Load method to the Person object. Enter the following code into the Person class module in the PersonObjects project:

Public Sub Load(SSN As String)
Dim objManager As PersonManager
Set objManager = New PersonManager
objManager.Load SSN, Me
Set objManager = Nothing
End Sub

This should look familiar, as it's pretty much the same code we just dealt with when having the client talk to the PersonManager. The code simply creates a PersonManager object, and then asks it to retrieve the object's data by passing the social security number and Me, a reference to the current object.

You'll now need to add a reference to the PersonServer project from within your PersonObjects project. Use the Project-References menu option, and select PersonServer.

It's worth noting, at this point, that the PersonManager object itself is entirely unchanged from our previous example. By simply adding a few extra lines of code into our business objects, we've dramatically simplified the UI developer's job, and we don't even have to change the objects that contain the data access code.

Updating the Person Object's ApplyEdit Method

Back to the Person object, we also need to change the ApplyEdit method to talk to the PersonManager:

Public Sub ApplyEdit()
Dim objManager As PersonManager
If Not flgEditing Then Err.Raise 445
Set objManager = New PersonManager
objManager.Save Me
Set objManager = Nothing
flgEditing = False
flgNew = False
End Sub

Again, all we've done is created a PersonManager object, just like we did in the UI of the previous example. Then we just call its Save method passing Me, a reference to the current object, as a parameter. Of course, the UI developer simply calls ApplyEdit to save the object to the database; they don't need to worry about any of these details.

Adding a Delete Method to Person

Finally, let's add a Delete method to the Person business object. After all, we've already got that capability built into PersonManager; we just need to make it available to the UI developer via the business object:

Public Sub Delete()
Dim objManager As PersonManager
Set objManager = New PersonManager
objManager.Delete udtPerson.SSN
Set objManager = Nothing
End Sub

The only real drawback to this implementation of a Delete method is that the UI code may cheat and continue to retain a reference to the Person object after the Delete method has been called. This can make it much harder to debug the UI, since the developer may not immediately spot the fact that they are still using an object that has theoretically been deleted. One solution to this problem is to maintain a Boolean variable inside the object to indicate that the object has been deleted. Using this variable, we can add a line at the top of every property and method to raise the appropriate error to disable them, as discussed earlier in the chapter.

This final approach to object persistence is a combination of the other techniques. It takes the best from each and puts them together to create an object to manage our data access that is transparent to the UI developer, easy to use for the business object developer, and that can be distributed to a central application server machine.

Testing the Code

The project should now run just as it did when we ran it under the full auspices of the PersonManager - we're able to perform deletions and apply edits as normal.

This is as far as we shall pursue our PersonDemo project. It's still in a pretty rough form, and there are lots of things we could do to improve it, of course; but the main functionality is in place, and it's served our purposes as we've explored a number of key concepts in this chapter. We're now ready to move on to bigger and better things - such as our video rental store project, where we'll develop the techniques we've learnt with our PersonDemo project to produce a sophisticated set of business objects and U

Page 12 of 13