[cgiapp] Model design in C::A/Titanium

[Richard Jones]

Ron Savage wrote:
> Hi Mark
>
> On Wed, 2008-10-22 at 22:35 -0400, Mark Rajcok wrote:
>> On Tue, Oct 21, 2008 at 7:45 PM, Ron Savage <ron at savage.net.au> wrote:
>
> [snip]
>
>>> But why /exactly/ is it growing?
>>
>> Ron, I wasn't too clear about who I was quoting. Richard Jones had the
>> growing Model class, so he would need to answer that question.
>
> Oops. My mistake.
>
>   

Yeah, was me :) Growing because I realised it would potentially end up 
with a very large number of methods. Pretty much as you have described 
in your Database.pm class - I calculated you have 44 so far. That's 
probably not excessive, but what about hundreds? So I decided to split 
my CRUD functions across several model classes, loosely related to the 
DB classes. To illustrate:

In my MyApp superclass I 'use MyApp::Model'. MyApp::Model is a single 
class which exports a method called model into the superclass namespace 
- so I can do $self->model('Foo')->function_name. In addition, 
MyApp::Model automatically pre-loads (in a BEGIN block) all MyApp::DB 
classes (Rose::DB::Object subclasses which contain db table meta data).

Then, a call to $self->model('Foo')->some_function($args) returns a (new 
or cached) MyApp::Model::Foo object where some_function() contains an 
RDBO method, eg $o->get_products_iterator(%$args).

This means all my db calls (or more correctly Rose method calls) are 
confined to my MyApp::Model::* classes, which means the controllers 
don't need to know anything about how Model::Foo::some_function CRUD's 
its data, and I could change Model::Foo to use DBIx::Class methods 
instead of Rose, and only have to change the method calls in that one 
class and not have to touch any of the controllers that get data from 
Model::Foo. Not sure how much of this conforms to "best practice", but 
it's working well so far.
-- 

Richard Jones