$user_object = {
    'uid' => 0,
    'user_name' => 'root',
    'projects' => [ 1,2,3,4 ], # project_id's
};
[download]

You have already had some suggestions about switching from database to flat file etc. Separation also holds for your user-interaction interface, whatever it is.

E.g., login.pl is clearly an interface thingy, so make it independent from your User-objects. That means: login.pl calls the user-class, and the user-class calls the database-interaction class, where login.pl holds the interface (web/CLI/GUI), user holds your (temporal) user data and the database class is left with calling whatever the database is.

You just apply this kind of reasoning to every relation you encounter while making up the program, and I think you will get around to some nice stuff pretty soon.

I'm not a real experienced OO'er or whatever, so listen to everybody else here for more advice. Browse tilly's nodes for example....

Cheers,

Jeroen
"We are not alone"(FZ)

I've never used any of these, but you can find information on these and other modules through Super Search or CPAN.

FYI, here's a post from the DBI list:

I just thought I'd let this list know that there's a comparison of persistence tools for Perl at http://poop.sourceforge.net. POOP stands for Perl Object-Oriented Persistence. There's also a mailing list for discussion of such things (poop-group@lists.sourceforge.net). The document as it stands compares a number of RDBMS-OO mappers as well as some OO-RDBMS mappers, including Class::DBI, Alzabo, and DBIx::RecordSet in the former category and Tangram and SPOPS in the latter.

And there's an article in this month's Linux World here: http://www2.linuxjournal.com/lj-issues/issue90/4887.html.

Your question is addressed exactly by Class::DBI. It is particularly good at translating database relationships into object methods, so your users and projects question all but disappears. Assuming you have a Class::DBI class for each of user and project, put this in the My::User class:

__PACKAGE__->hasa_list(
    'My::Project', 
    ['name_of_field_in_project_table'],
    'projects',
);
[download]

And then to retrieve the projects all you have to say is:

my $user = My::User->retrieve($id);
my @projects = $user->projects();
[download]

I use it all the time and i can't recommend it highly enough.

Thanks for the suggestion, Class::DBI is working well for me now.

fx

Great question!

Two approaches seem attractive to me. First, you could code a method that loads data from the db into an object, and provide a way to call it from the constructor. Or you could make a User::Database class to handle communications with the database.

The first option is more compact and would be quite servicable. If you have an object method that loads data from the db that is separate from the constructor, you gain some flexibility--you may want to reload a User object's data at some point. For convenience, it would be nice to be able to load data into an object when calling it. Since the load method would need to know what object to load data into, it makes sense to make load an object method.

Class methods are good for things that operate on the all the instance of a class, like an instance counter. A method that flushes all user objects to the database is a good example. You could have a class array that stores a ref to each object. Your class method User_flush_all could loop through the array and call a flush oject method on each user.

Making a User::Database class to handle db connections is a great idea. It allows you to abstract the issue of persistance. This way, if your company falls on hard times and you can't afford that Oracle server anymore, you can easily modify User::Database to use DBM files or mySQL or whatever. Of course there are the excellent DBI modules that already some of this abstraction, so it may not be worth it to separate out the persistance code. It's all a tradeoff of time/cost vs. flexibility.

As to the loading of Projects for Users, I would favor an approach where project data was loaded only when needed. Perhaps each User should have attributes for Project_IDs => [1, 2, 3, 4,]; and for Open_Projects => [Project(0x884204),Project(0x883204),Project(0x886504),]. So when you want to look at a project, you call $project = $user->open_project($project_id) which creates a new Project and adds the project to the Open_Projects array for that user. In this way you can avoid the memory bloat and startup lag of loading all a user's projects.

TGI says moo

$U = User->new( $user_name );
# at this point there is a minimal amount of data for the User object,
+ but it should still be functional
$U->LogIn();
# handles all of the database connection activity, loads in user info 
+as well as populates project list, etc.
[download]

I'm wary of object/relational mapping tools for various reasons, but a lot of people seem to like SPOPS and Class::DBI for automating these steps. If your objects map to database tables in a simple way, these could save you some coding.

I'm not really sure what your user object looks like so this make or may not work:

Instead of trying to populate the user object with an array, why not try passing the database output directly to it with a hashref? I've used this method on several projects:

my $query = "SELECT * FROM users WHERE user=?";
my $sth = $dbh->prepare($query);
$sth->execute($user) or die $sth->errstr();

# Here you have all the user's info in a hashref. The
# keys are the same as the database column names.
my $row = $sth->fetchrow_hashref();
# Then you could call the new method:
my $user_info = User->new($row);
[download]

Then your user info new method basically could just bless the input

package User;

sub new {
     my($class,$user_info) = @_;
     return bless $user_info,$class;
}
[download]

Hope that helps