Should I use destructor to save object back to DB?

I'm building a a collection of objects, subclass of PEAR, for a web app I'm building. The main purpose of these objects is to serve as an interface to a database that hold info such as members, email addresses, phone numbers, etc. I'm building objects like Email and can build its constructor to build the object based on IDs very nicely. I was hoping to use the destructor to save any changes made to the object but it seems I can't do it easily because to my understanding the destructor isn't called until after PHP is done executing and in many cases (in particular PHPUnit tests) I need to execute more code after the save and will expect the new data to be in the DB. One solution is to write an object function called saveToDB and call it manually whenever I need to push data to the DB before executing more code after the fact and then simply put the same saveToDB in the destructor so I can avoid calling it on simpler pages. To me though this might make it confusing to new people seeing the code and lends me to think that perhaps I should simply always use the saveToDB function manually and forget the destructor all together. Your thoughts? ~ Mike ----- Mike Zornek Web Designer, Media Developer, Programmer and Geek Personal site: <http://MikeZornek.com> New Project: <http://WebDevWiki.com>