[Catalyst] Refactoring question

[Bill Moseley]

On Thu, May 27, 2010 at 5:38 AM, Steve <steve at matsch.com> wrote:

> I think your business logic should be moved to the model, not the
> controller.
> The model does the heavy lifting.
>
>
>  My model is currently comprised only of my DBIC Result and ResultSet
> classes.  Are you suggesting that some of the logic in my controllers sho=
uld
> be moved into my DBIC classes, or should I create new Moose classes.  If
> Moose, how do I 'hook up' those classes to Catalyst?
>

There's always room for another layer of abstraction.  That said, I find
that adding custom ResultSet and Result methods (and using custom base
classes for both) handles most of the abstraction.  You can abstract most
calls so that you aren't writing little, if any, DBIC-looking code in your
controllers.  The Controller actions should be pretty tiny -- just a few
lines at most.

"Decouple as much as possible. If you have to fire up your web application
> in order to test database insertion, that's wrong. Build the model so that
> you can use Perl one liners to manipulate data through it."
>
>
True, although I've been working on an app that is entirely AJAX-based so
the Catalyst app is exposed as an API of URLs (I'll avoid the term REST
here).  So, that means all access to the app is via the API -- even for cron
scripts. As a result, the bulk of the tests are talking to the app via URLs
and HTTP method names.  (PUT /user/1234).  We still have tests for the
model, but no other code uses the model directly (by contract). We still
push as much code low into the model as possible.

And to your original post:

Take a look at
http://search.cpan.org/~masaki/Catalyst-Controller-Resources-0.08/ .

I would split up your existing controllers.  Think about the objects
returned and name them them the same.  I often have model class names that
are the same as controller class names (and form classes).   Need to get a
user?  /user/$id  Instead of a verb like /ViewStmt use a name for the thing
you want:  /statement/$id or /invoice/$id.  I'd be interested to hear
opinions about your admin interface,  but, I often mirror existing
controllers with /admin/user/$id  (admin's view of a user).

I often have a /login controller -- POST /login creates a new token
(cookie).  Then there's room for /login/forgot_my_password kind of thing.



-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/catalyst/attachments/20100527/b4ce7=
d35/attachment.htm