Now that we’ve seen the Model class and all its supporting classes, let’s look at how it is used in practice. The following snippets of code would be part of the Controller layer of the application: the layer that performs all the logic. Note how all the actual database calls are hidden from this layer. It uses just calls to the Model class.

Each file in the Controller layer indicates that it will use the Publisher class:

use CBDB::Publisher;
my $VERSION = 1.0;

A new object is created as follows:

my $pub = new CBDB::Publisher(  );

Now let’s set some data. The following creates a new publisher in our program (but not the database). We’re in a hurry, so we can’t be bothered with good spelling.

$pub->setName("Joe's Boks");

Note that we didn’t set the id field of the publisher. The ID is an auto-increment field taken care of automatically by the database. A more abstract way of understanding our approach is that the ID is not a real-world property of this object. It exists only because the object-relational model we’re using internally requires it. Therefore, at the controller level, we don’t have to worry about assigning it or making sure it’s unique.

We’ll see what we just created:

print 'Our new publisher is ' . $pub->getName(  ) . "
";

If the program were to terminate at this point, this object’s data would be lost. To make it persistent, we need to save it to the database:

$pub->create(  );

Now the object has been created in the database and can be retrieved by another application, or by our application during a subsequent run. The database has assigned a primary key, which we can store for later use to find the object again:

my $new_id = $pub->getId(  );

Suppose we want to retrieve the object in another part of our program. We’ll use the getByPrimaryKey( ) call with the ID we stored earlier. The getByPrimaryKey( ) is static; we call it on the Publisher class itself instead of on an object from that class.

my $pub2 = CBDB::Publisher::getByPrimaryKey($new_id);

Because of the caching mechanism, $pub2 is the same object in memory as $pub. We can check this identity, if we’re curious.

if ($pub2 != $pub) {
   print "Whoops! Something isn't working right!
"
}

Let’s change some data. For instance, we can fix the typo we introduced at the beginning of this section.

$pub2->setName("Joe's Books");

At this point, the data has been changed in the object only, not in the underlying database. However, because all active instances of this object in our program are references to the same object, this change takes place everywhere in the application immediately. Thus, the following statement will print Joe's Books, not Joe's Boks, even though we didn’t explicitly touch the data to which $pub points.

print "The publisher's name is now " . $pub->getName(  ) . "
";

Now let’s save these changes to the database. We can use either $pub or $pub2 to indicate the data.

$pub2->update(  );

Later, we decide we’re finished with this data and need to delete the row from the database.

$pub->remove(  );

The underlying row in the database has now been deleted. However, this object (as well as $pub2) still contains the data until the program terminates or destroys the objects. This may be useful in case we want to refer to some property that the publisher used to have, as we do in the informational message below.

print "The publisher " . $pub->getName(  ) . " was just erased.
";

We hope that this little tour has shown the value of planning your program’s structure so it is flexible and maintainable. Underneath DBI and CGI and the MVC methodology, it’s just a bunch of INSERT, SELECT, and other SQL statements.