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

[Mark Rajcok]

On Tue, Oct 21, 2008 at 7:45 PM, Ron Savage <ron at savage.net.au> wrote:

> Hi Mark
> > > 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
> > > 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
>
> 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.

I've just had a look at my Local::Contacts::App::Database.pm, and it
> contains methods with these sorts of names:
> o get*. 27 methods (gasp!)
> That's what you get for using DBIx::Simple rather than a full-blown ORM
> such as Rose.
> And for eschewing AUTOLOAD.


I'm not an AUTOLOAD fan either, but when I considered the number of get/set
methods I'd have to write for my new application, I decided to use it (for
the first time).


> I'm comfortable with all those being in Database.pm. Are you :-))? [Not
> really]
> What else are you putting in there?
> Are you sure you're not adding too much complexity here because someone
> somewhere once did it that way? [I gave it a lot of thought (many days, and
> discussions with friends at work)... I've created two projects with
> CGI::App, and I'm now on the third.  I consider my new approach much
> superior to my previous approach.  Cleaner separation, and the code is easy
> to read/follow (IMO) -- my brother will be coming on board to help me, so
> it's important that I don't abstract everything too much.]
> Can you give me an idea is to what would go into the base class of such
> a set up?


I will answer these questions in more detail when I create a Google Doc (in
a few weeks??) with all of the code, and a good bit of discussion.  I wanted
to make a comment on this thread though... to see what other people do (so
thanks for responding), in case there was a "better" way.

> Also, what if you need to create more than one Foo object in a runmode?
>  The
> > "auto instantiate" mechanism won't work.
> > With the code I show above, a runmode can create multiple user objects if
> > needed:
> > my $user1 = User->new(...);
> > my $user2 = User->new(...);
>
> This is a very interesting comment.
> Thinking about it, I see my code would /never/ create a Person object (I
> have no such thing, funnily enough).
> My Person.pm is my person-controller object. It takes decisions because
> it contains all person-related run modes.

If it wants person data, it calls Database.pm's some_method() to get a
> data structure, which then gets formatted into either HTML or JSON.


So if you need more than one Person (object), you'd have to create a
some_other_method() in Database.pm.  Sounds like a lot of methods in
Database.pm might pop up over time.


> I suppose I could have designed a person object, and gotten the
> controller to create an instance, then gotten the database to populate
> whatever bits a specific run mode was interested in, and then gotten the
> person object to format those bits for output. That would mean this person
> object was a person view component in a MVC structure.


Not quite.  Yes, the controller creates and User object, then calls "load()"
on the object to load it from the database.  However, the person object
never formats the bits for output -- that's the job of the view (HTML
template), not the model.  The controller populates the view/HTML template.


> I've just never bothered adding that sort of complexity. The formatting
> - such as it is - takes place right in the controller, my Person.pm.


I like having HTML template files and separate model classes... for this
reason:  if I add a new field to the User table, then normally only the
"add/edit" user HTML template and the User.pm class need to change.

I have not started thinking about how I'm going to do table joins yet.  I
may end up with a Database.pm-like class for that...

-- Mark