Best Practice: Catalyst and DBIx::Class

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

Hi Everyone,

I need help in deciding on the best practice for catalyst and DBIx::Class. I've been using Class::DBI for awhile and trying to convert to DBIx::Class for developing a web application.

In the past, I've been using Class::DBI as a separate application (as a library), so that it can be used for more than one application, but I've been reading the catalyst manual docs for DBIx::Class that is suggesting that it is to be stored within the catalyst application.

so my question is,

1) What is the best practice on matters like this?, is it better to separate it, create the DBIx::Class as a separate library, or just let it be in one application?.

2) If I wanted to go for the separate library route, is there a good documentation on how to integrate it with catalyst?, so that I can still access the database using the $c->model() function like below

$c->model('MyAppDB::Somethis')->search({id => $id})->delete_all;

Thank you so much for the help, Please let me know if anyone don't understand what I mean.

Comment on Best Practice: Catalyst and DBIx::Class

Replies are listed 'Best First'.
Re: Best Practice: Catalyst and DBIx::Class by Your Mother (Archbishop) on May 07, 2008 at 05:57 UTC
What many of us do, probably most of the experienced Cat devs, is to keep the schema separate from the Cat app, though often in the same namespace. So you have MyApp::Schema and MyApp::Schema::Tables or MyApp::Schema::FatModel and then your model class is nothing but an import of the schema with some connection information for the application. `package MyApp::Model::DB; use strict; use base qw/ Catalyst::Model::DBIC::Schema /; __PACKAGE__->config ( schema_class => 'MyApp::Schema', # et cetera` [download] It can be confusing at first because the abstractions are pretty deep but it's very powerful and lets you reuse your schema anywhere (command line, standalone service, one-offs) without loading your app since it ignores anything outside the M/V/C namespaces.	[reply] [d/l]
Re^2: Best Practice: Catalyst and DBIx::Class by confused_elf (Novice) on May 07, 2008 at 09:59 UTC
I see, I'm also leaning on having it separated. Thanks a lot for the reply and the code example. Thanks.	[reply]
Re: Best Practice: Catalyst and DBIx::Class by perrin (Chancellor) on May 07, 2008 at 12:30 UTC
Using the `$c->model('Foo')` syntax doesn't really get you anything over using the modules directly. If that's the only reason you're considering changing things, it's probably not worth the bother.	[reply] [d/l]
Re^2: Best Practice: Catalyst and DBIx::Class by Your Mother (Archbishop) on May 07, 2008 at 17:28 UTC
This is a fine way to do it but if you don't put things in your model space you likely end up instantiating the schema over and over which is annoying (to) code. Plus, while it's definitely not a best practice, it is sometimes nice to be able to do DB hacking in templates where debugging and prototyping can be faster and easier. I am not a PHP fan but it's pretty obvious why it became so popular -- having DB access in the template may be hacky but it's pretty damn useful and quick. `[% foo = c.model("DB::Foo").search_rs() %] [% foo.count() %] foo[% foo.count() == 1 ? "" : "s" %] in the DB` [download]	[reply] [d/l]