On 5/27/2010 9:41 AM, Bill Moseley wrote:
On Thu, May 27, 2010 at 5:38 AM, Steve <[email protected]>
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.
At present, the only DBIC-looking code is contained in two lines
(chaining resultsets). I'm not sure it's worth the effort for this
application, but it certainly will be for others. Can you elaborate on
the custom base classes idea? If my Catalyst model is: "use base
'Catalyst::Model::DBIC::Schema'", would it then become "use base
'MyApp::Model::Custom'", then MyApp::Model::Custom uses
'Catalyst::Model::DBIC::Schema'?
"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:
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).
In which case the controllers would be...? Admin, User, and Statement?
I'm not sure I am quite ready for ANOTHER layer of abstraction...yet. :-)
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
[email protected]
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.819 / Virus Database: 271.1.1/2899 - Release Date: 05/27/10 02:25:00
|
<<attachment: steve.vcf>>
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
