[Catalyst] Making Controllers thin and Models thick

[Dave Rolsky]

On Wed, 18 Jul 2007, Kee Hinckley wrote:

> 2. Biz-logic
> Things you've specified for you application.  E.g. We need an email address 
> for all new accounts
>
> 3. DB
> Constraints specific to the database and object model.  E.g. Field length, 
> required fields.

The distinction between these two is pretty artificial. To give a simple 
example, think of most foreign key uses. If I have a table "Post" and a 
table "User", and a foreign key such that Post must have a valid user_id 
from User, that's business logic. It says that "posts must be associated 
with a valid user".

If SQL DBMS products didn't suck quite so much, I'd be able to say "posts 
must be associated with user who is not marked as deleted".

Basically, your distinction for #3 seems to be "stuff I can trivially 
define with the SQL implementation I happen to be using".

Having this sort of stuff in the DBMS is _in theory_ a good thing, as it 
actually ensures that the data you store is only valid data, according to 
the rules you've defined.

Unfortunately, in practice, doing this becomes very cumbersome. My take on 
this is that it's the lack of sophisticated declarative constraints that 
makes this so. Using triggers and stored procs is a bit gross, and I think 
many developers perceive it as "too opaque".

Another problem is that translating the errors the DBMS gives you into 
something user-friendly can be a pain, and there's not a good standardized 
way of passing DBMS-side validation errors back to Perl code, so you get a 
string and have to parse it, which feels horribly fragile. Also, that the 
DBMS will generally blow up on the first constraint that's violated, 
rather than giving you a set of errors ("first name is required", 
"password must be >6 characters").

Personally, I'd much rather define my business logic using a rich 
declarative constraint language rather than in app code. As mentioned in 
another message, Pg does make this a little easier, since declaring custom 
types based on built-ins isn't really hard, so you can have a type like 
"email_address", and say that it's a string which matches ".+ at .+\..+", 
which is a small step towards declarative business logic constraints.


-dave

/*===================================================
VegGuide.Org                        www.BookIRead.com
Your guide to all that's veg.       My book blog
===================================================*/