Quite confuse about using Class::DBI to implement Data Access Objects and Value Objects Design Patterns

monsieur_champs has asked for the wisdom of the Perl Monks concerning the following question:

Fellows,
I'm starting a new Perl project, and our team system architect is a guy from Java OO school. I'm trying to help him to understand and use the Perl Class::DBI family, making analogies with J2EE object families so he can understand and model what's going on.

I've implemented a small prototype for part of our application, so I can demonstrate Class::DBI in action. So I wrote something like this (simplified for this article):

package Project::CDBI;
use base "Class::DBI";
__PACKAGE__->connection( __DSN__, __USER__, __PASSWORD__ );
1;

package Project::CDBI::User;
use base "Project::CDBI";
__PACKAGE__->table( 'user' );
__PACKAGE__->columns( All => qw/ id name login passwd email / );
__PACKAGE__->sequence( 'user_id_seq' );
1;

package Project::Main;
use strict;
use warnings;
use Project::CDBI::User;

# many lines of code here...
# somewhere here we find a user and change his email.
$user = Project::CDBI::User->find_or_create( $user_id );
$user->email( $new_email_addr );
$user->update;
Project::CDBI::User->dbi_commit;
__END__
[download]

And then it happened. The architect asked me to use DAO design pattern to implement the database access, and to use VO (Value Objects) to pass info arround. I just can't point him what object plays the Value Object role and what object plays the Data Access Object role when using Class::DBI.

Given that, a enlightened and wise monk here can please tell me what are the roles each perl object implemented here plays and what should I do to implement that Value Objects and Data Access Objects the architect asked me to?

May the gods bless you all.

-- monsieur_champs

Comment on Quite confuse about using Class::DBI to implement Data Access Objects and Value Objects Design Patterns Download Code

Replies are listed 'Best First'.
Re: Quite confuse about using Class::DBI to implement Data Access Objects and Value Objects Design Patterns by Ovid (Cardinal) on Aug 10, 2005 at 19:53 UTC
Be sure to ask him to submit all requests as UML diagrams, in triplicate, with TPS cover sheets and circles and arrows and a diagram on the back of each one. On the other hand, if you want to keep your job, maybe digging a little deeper is the way to go here. Maybe your architect knows what he's doing. Maybe he has solid, concrete reasons for asking you to do this. There's also the possibility that he's just parroting what he knows (I've had to work with such a boss. It's not fun.) Does the architect understand the strengths and weaknesses of Perl? What works well in one is frequently a horrible mistake in the other. The languages do not translate easily into one another. A classic examples is Lucene. It's Java. It's powerful. It's fast. Then it was ported very faithfully to Perl and called Plucene. In Perl it doesn't scale well because it's so darned slow. Does this mean Perl can't handle stuff like this? No. Search::KinoSearch is a new search engine written in Perl and it doesn't have the same performance problems. Personally, I am very leery of Perl or Java gurus trying to be the architect on the project written in the other's language. I know Java, but I'd hardly qualify as an architect. I'd be going around asking silly questions like "why don't you just build a bunch of custom closures for callbacks?" And the Java guys would rightfully snear and make posts very similar to yours. I know that doesn't answer your question (I'm hopeful that someone else can), but I thought it might shed a little light on another way of looking at the situation. Cheers, Ovid New address of my CGI Course.	[reply]
Re^2: Quite confuse about using Class::DBI to implement Data Access Objects and Value Objects Design Patterns by monsieur_champs (Curate) on Aug 10, 2005 at 22:16 UTC
Be sure to ask him to submit all requests as UML diagrams, in triplicate, with TPS cover sheets and circles and arrows and a diagram on the back of each one. Thanks for the recommendation. I'm really well-served on bureaucracy, believe me. The client have a CMM L2 certification and all projects must fulfill a lot of bureaucratic requirements. :-( On the other hand, if you want to keep your job, maybe digging a little deeper is the way to go here. Maybe your architect knows what he's doing. Maybe he has solid, concrete reasons for asking you to do this. Not really. He have a Java based mindset, just that. It's not his fault, he actually works with Java. perrin and izut arguments are enough to convince him about the non-need of VOs for implement a good DAO in Perl. The Lucene and Plucene examples Thanks for those. They were nice and very illustrative. It started to show the light to my poor architect. :-) May the gods bless you for this example and him for accepting it as a good starting point. And the Java guys would rightfully snear and make posts very similar to yours. Oh, please! I'm not sneaking. I'm posting this with the agreement of my architect. We are good friends, and both of us are having fun with this project. :-) BTW, thank you very much for you point of view, it was quite useful. And thanks to perrin and izut for pointing good solutions for avoid extra coding and still having high quality Perl code. -- monsieur_champs	[reply]
Re^3: Quite confuse about using Class::DBI to implement Data Access Objects and Value Objects Design Patterns by Ovid (Cardinal) on Aug 10, 2005 at 22:49 UTC
In reading my original response, I see it was a bit more snarky than it should have been. I fear that I've had to deal with "Java is the Best" folks before and I have a bit of a knee-jerk reaction when I get a whiff of someone who's not thinking beyond their particular favorite tool (including Perl). It sounds like you have a good situation going there where both of you can win. That sounds great. If your architect read my post, extend my apologies if I offended. That wasn't intentional! Cheers, Ovid New address of my CGI Course.	[reply]
Re^2: Quite confuse about using Class::DBI to implement Data Access Objects and Value Objects Design Patterns by perrin (Chancellor) on Aug 10, 2005 at 20:19 UTC
Sort of off-topic, but I recommend SWISH-E as a search engine. It's easy, very fast, scales well enough for all "normal" uses (we search tens of thousands of docs with it), and has a nice Perl API.	[reply]
Re: Quite confuse about using Class::DBI to implement Data Access Objects and Value Objects Design Patterns by izut (Chaplain) on Aug 10, 2005 at 20:28 UTC
VOs are mostly used in J2EE applications which uses EJBs, IMHO. It's cheaper transfer a Value Object in place of an EJB object itself, in distributed applications. I don't see the need to implement VOs within Class::DBI, unless you are using SOAP and want to return the representation of your Class::DBI implementation. Another point I see is you can't think in Java when programming in another languages. Tell your architect to think in Perl when programming in Perl, think in Java when programming in Java (I can't think in Java anymore, that's the reason I program in Perl ;). Igor S. Lopes - izut surrender to perl. your code, your rules.	[reply]
Re^2: Quite confuse about using Class::DBI to implement Data Access Objects and Value Objects Design Patterns by monsieur_champs (Curate) on Aug 10, 2005 at 22:00 UTC
No, thanks. It's cheaper to me keep the DAO and the VO roles in the same object. I'll use the Class::DBI for both things, and that's fine. Please don't blame my architect. He's learning Perl from scratch, for this single project... it's not his fault. ;-) -- monsieur_champs	[reply]
Re: Quite confuse about using Class::DBI to implement Data Access Objects and Value Objects Design Patterns by perrin (Chancellor) on Aug 10, 2005 at 20:23 UTC
There is no need to use Value Objects in Perl. These can just be hashes. Class::DBI classes are your DAOs.	[reply]
Re^2: Quite confuse about using Class::DBI to implement Data Access Objects and Value Objects Design Patterns by Transient (Hermit) on Aug 10, 2005 at 20:41 UTC
This is spot on. The DAO is just an abstraction layer to your actual datasource. The VO's are unnecessary, but then again, it wouldn't necessarily hurt to make a specific one - after all, most objects in Perl are just blessed hashrefs. Throw in some auto-generated getters and setters and you're done.	[reply]
Re^2: Quite confuse about using Class::DBI to implement Data Access Objects and Value Objects Design Patterns by monsieur_champs (Curate) on Aug 10, 2005 at 22:02 UTC
Shall I use VOs at all? Or this is kind of a purist approach to the problem? Thanks for answering! -- monsieur_champs	[reply]
Re^3: Quite confuse about using Class::DBI to implement Data Access Objects and Value Objects Design Patterns by perrin (Chancellor) on Aug 10, 2005 at 22:23 UTC
In Java, VOs are usually a solution to the problem that remote method calls are very slow and DAOs are often implemented with something that uses remote method calls, like old-school EJBs. I don't think you need them. I don't use them in my perl stuff. It is normal in perl to call methods passing in a hash (the standard "named parameters" pattern). This should be enough.	[reply]
Re: Quite confuse about using Class::DBI to implement Data Access Objects and Value Objects Design Patterns by lachoy (Parson) on Aug 11, 2005 at 16:56 UTC
It's probably worth mentioning that Java (even Enterprise Java tm) is generally moving away from this use of Value Objects, making persistent objects simple java objects instead of heavyweight entities. Chris M-x auto-bs-mode	[reply]