I have been playing around with Class::DBI to see why everyone loves it so much and I cannot figure it out. You have to set up your own database and tables. Then you have to tell the class about your table and it's structure. Then, you have to learn the class's new syntax for dealing with a relational database which is less flexible than the SQL which you must already know since you had to set up your own table in the first place!
That's not entirely true. It all depends on how you use it. You can use things like Class::DBI::Loader::mysql to have your class examine the table and create all the column accessors. This is not included by default for various reasons (the overhead in a non-persistent environment, database specific features, etc).
You can then use things like Class::DBI::AsForm to generate forms from your database.
You can also map certains types of columns to 'inflate' into an object or your choosing. For instance, having date columns inflate into DateTime objects, etc.
You can also separate your concerns so that all of you SQL (if you have any at all) is in one place.
You have several built in methods for searches, column accessors/mutators, etc and when ever you need the power of SQL you can write in SQL.
You also have many Class::DBI::Relationship modules to help you model your data in an easy OO fashion.
The only benefit I can see is that you can move your code to different databases without change, but I would prefer a solution that abstracts the database interaction completely where you can design forms and modify them and the database will shape itself to fit the forms.
I think having the forms dictate the db design is a bad idea. I know that they influence it, especially in which fields might exist in the database, but I think that the relational design of you data is a separate concern than how a particular form looks. And besides, forms are just a part of web applications.
I love Class::DBI because I can set up my model and then do something like this in my C::A app:
my @people = MyApp::DB::Person->retrieve_all();
and then in my template (TT)
<table>
<tr>
<td>First Name</td>
<td>Last Name</td>
<td>Birth Date</td>
</tr>
[% FOREACH person IN people %]
<tr>
<td>[% person.first_name %]</td>
<td>[% person.last_name %]</td>
<td>[% person.birth.ymd('-') %]</td>
</tr>
[% END %]
</table>As far as telling Class::DBI about the database structure, I don't understand why. It seems fairly easy with DBI functions to have a program read database structure itself.
Class::DBI isn't meant to replace DBI and even isn't a good fit for a lot of problems. It does do a lot more than you gave it credit for though.
-- Michael Peters Developer Plus Three, LP
--------------------------------------------------------------------- Web Archive: http://www.mail-archive.com/cgiapp@lists.erlbaum.net/ http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2 To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
