Okay, so some other programmer will be writing, say, a command line script that requires connection to your DB, and you want them simply to create an object to give them access to your data. I was thinking mostly in terms of requests coming in through a web server.

One option then is to write a module with a constructor capable of creating the connection, which is in turn instantiated as part of the instantiation of your user data access module. Here's a rough and ready sketch:

package UserDBConn;
sub new {
  my ($class, $param1, $param2 ...) = @_;
  my $this = bless({}, $class);
  # store the returned DB handle in a private slot
  $this->{_db} = DBI->connect($param1, $param2 ...);
}
sub getDBHandle {
  return $_[0]->{_db};
}

package User;
# lexically scoped at file level so you can create multiple
# instances of this module within this process using the 
# same UserDBConn. Creating a new DB connection each time 
# you want to pull out a user's information would be *bad*.
my $user_db_conn; # = new UserDBConn(...);
sub new {
  my ($class, $username, $more_stuff) = @_;
  my $this = bless({}, $class);
  $user_db_conn ||= new UserDBConn(...);
  # now use $user_db_con->getDBHandle() to populate $this
}
sub setX {}
sub getX {}
sub save {
  # write all our data to the table
}
[download]

This approach has the benefit of creating a reusable custom wrapper module around your DBI connection, meaning you can utilize it in other circumstances. Plus you've got the separation of business logic dealing with your user data from the database connection logic. And, your fellow programmers in other departments have no need to know anything about the DB connection under the covers.