[Catalyst] (no subject)

[Justin Tocci]

Dominique Quatravaux had this to say to Perrin:
> ... preventing nonsensical updates of the model is also
> profitable to non-Web parts of the app such as crontabs, so it is best
> done in the model (or even deeper, directly within the database using
> SQL triggers or such).

I agree. When we start talking about SQL triggers, views, rules and  
other database actions, there is data protection code and data  
methods. I have an inventory application that is written entirely in  
the database. Users interface to it using only Select, Update, Delete  
and Create actions (DUCS?) on views. In this way I only have to count  
on the front end application for the basic CRUD actions, enabling me  
to move from Microsoft Access to the web more easily. In this app, I  
have some code that prevents the user from making a mistake (data  
protection), and I have some code that does things specific to this  
company, such as process a list of parts in a certain way, (data  
methods). Just for clarity, I want to point out I wasn't referring to  
this code as 'business logic'. Though I know many would disagree, I  
look at this as entirely model stuff. I think even those who don't  
like code in the database will admit, these things sometimes don't  
perform well if they aren't put in the database, and I have a  
personality defect that inclines me to put it all there if I have to  
put some of it there.



justin tocci
Fort Worth, Texas