On Thu, May 27, 2010 at 5:38 AM, Steve <st...@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 should > 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 mose...@hank.org
_______________________________________________ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/