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

[Porta]

Richard.
I'm not very experienced, but in my case it worked NOT to crowd all
the models into a single module. I'd recommend to have a main
db-access module and subclass it according to your different needs, as
you said here:

"Ideally I would move the WebApp::Model methods into their respective
WebApp::DB class (eg get_foo() goes into WebApp::DB::Foo), but then I
can't access it any longer from $c->param('model')->get_foo."

I guess that I'm missing something here, because I don't see why you
need to crowd all the models into a single one. You can still decouple
the models from the controllers if every subclass of WebApp::DB knows
how to interact with the database. Then, instead of

    $c->param('mode')->get_foo();

you'll do:

    my $foo = WebApp::DB::Foo->new;
    $foo->get_all();

Where get_all is a sub inherited from WebApp::DB.

Also, the same way, you'll be able to use the get_all() in
WebApp::DB::Bar, WebApp::DB::Baz, etc;


Makes sense?

Julián Porta.



On Tue, Sep 23, 2008 at 9:36 AM, Richard Jones <ra.jones at dpw.clara.co.uk> wrote:
> I know we've been around here before in some related topics, but I would
> appreciate some feedback on a possible MVC structure for a Titanium/CGI::App
> that I am currently building.
>
> I'm using CA::Dispatch to allow multiple apps with a small number of rm's
> each. Views are handled by CAP::TT. Just the Model aspect is proving a
> little challenging. I'm trying to ensure that all database calls are handled
> outside the controllers, and to this end am using a module called
> WebApp::Model
>
> #####################
> package WebApp::Model;
>
> BEGIN {
>  setmoduledirs('/path/to/app'); # Module::Find
>  useall WebApp::DB; # Rose::DB::Object classes
> }
>
> sub new {
>    my $class = shift;
>    bless { }, $class;
> }
>
> sub get_foo { }
> sub update_bar { }
> sub delete_baz { }
> #####################
>
> WebApp::Model initially loads all WebApp::DB::* (Rose::DB::Object) classes,
> and is made available to the WebApp object via cgiapp_init:
>
> #################
> sub cgiapp_init {
>  my $c = shift;
>  ..
>  $c->param( 'model' => WebApp::Model->new );
> }
> ################
>
> Each controller run-mode uses $c->param( 'model') to get its data:
>
> ######################################
> sub foo : Runmode { # CAP::AutoRunmode
>  my $c = shift;
>  ..
>  my $data = $c->param('model')->get_foo;
> }
> ######################################
>
> This seems to work well, but the problem is that WebApp::Model is growing,
> as ever more (unrelated) db-related methods are added. Perhaps I
> could/should sub-class this one? Ideally I would move the WebApp::Model
> methods into their respective WebApp::DB class (eg get_foo() goes into
> WebApp::DB::Foo), but then I can't access it any longer from
> $c->param('model')->get_foo.
>
> But the main question is whether this is the right approach to start with -
> stuffing WebApp::Model into the WebApp object and retrieving it in the
> run-modes via a param_name. Advantages include decoupling the model from the
> controllers - they don't know/care how get_foo() gets its data, and I can
> change the db-related stuff (eg RDBO <=> DBIC) without affecting the
> controllers. Disadvantage (so far) is lumping all methods into one
> (WebApp::Model) module. Comments & thoughts most welcome.
> --
> Richard Jones
>
> #####  CGI::Application community mailing list  ################
> ##                                                            ##
> ##  To unsubscribe, or change your message delivery options,  ##
> ##  visit:  http://lists.openlib.org/mailman/listinfo/cgiapp    ##
> ##                                                            ##
> ##  Web archive:   http://lists.openlib.org/pipermail/cgiapp/   ##
> ##  Wiki:          http://cgiapp.erlbaum.net/                 ##
> ##                                                            ##
> ################################################################
>
>