[Catalyst] Models and inflating

[Jonathan Rockway]

* On Mon, Feb 23 2009, Alexander Tamm wrote:
>>> It looks a bit weird to me, but it seems to work. Should it work?
>>
>> You shouldn't do this (*), it is very confusing.  Put functions like
>> this in the row class, i.e. YourApp::Schema::Foo::User, so that all
>> users of the schema have access to these methods.
>
> The reason I want to do this (or something similar) is that I don't
> want all the database-specific cruft in the class I'm editing. I'm
> trying to keep the classes clean and separate the storage from the
> functionality. If I put the functionality in the Schema::*, I will
> have about 400 lines of code that I need to replicate across eight or
> more sites and the classes won't be usable without DBIx::Class or
> Catalyst.

No, your current solution is the one that's not usable without Catalyst
and DBIC.  If you just want some random classes, you write them:

   package Class;
   use Moose;

   has 'some_row_object' => (
       is => 'ro',
       does => 'Some::Interface',
       required => 1,
   );

   # code goes here

   1;

I usually "wrap" the DBIC classes like this when I have operations that
logically operate on a group of "unrelated" (in the DB) objects, or
operate on two separate schemas.  (What most people do in the controller
I do in what I call "Backend" classes.  It's the glue between the
low-level DBIC stuff, and high-level operations.)

If your classes depend on the structure of DBIC results, then the code
needs to go in your schema classes.  That is how everyone does it.
(Your "full_name" example is just the sort of thing that you would keep
inside DBIC.)

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"