[Catalyst] Making Controllers thin and Models thick

[Bill Moseley]

On Wed, Jul 18, 2007 at 07:49:50AM -0700, John Napiorkowski wrote:
> I've come to the reluctant conclusion that for
> anything other than trivial applications you will need
> to validate in a couple of places.  Obviously the
> database should be properly designed to enforce
> integrity rules.  If you are using a database that
> let's you create custom types, like Postgresql, you
> can take it a bit further and actually create self
> validating types for your columns.  I do this for very
> common things like email addresses.  Postgresql is
> nice for this since you can create custom types and
> domains using Perl as your procedural language.

Yes, validation is a bit generic of a term.

For me, the database should try and enforce a valid state of
the application.  An order row better reference a customer row.
An order status better reference a valid value in the status table or
have a valid check constraint.

Doesn't mean a bit of raw DBI can't hose the application, of course.

For application state changes I try and abstract that into a method in
the model.  I rarely have ORM specific code in the controller.

I tend to not validate things like email addresses or phone numbers at
the RDBMS level -- it's not critical to the state of the application
typically.  That's left to an I/O layer that is my user input
validation code.  That code can be used outside of Catalyst -- and
as I commented before, it's not tied to the model/ORM either.

Application state changes are typically caused by user input. And user
input is often multiple fields.  So, it makes sense to defined
forms for handling a set of fields all as one unit.  That validation
is also not easily defined in a static configuration file (or by
constraints on the database) so it also makes sense the forms are
bundled with code.

I doubt there's any best approach.  But, if the idea is thin
controllers then I like using one line of code. ;)

-- 
Bill Moseley
moseley at hank.org