[Catalyst] Where should constraints go

John Siracusa siracusa at gmail.com
Fri Nov 3 16:50:13 GMT 2006


Keep in mind that there are at least three possible levels of
constraints in a database-backed web app.

1. Constraints enforced by the database (e.g., maximum length for a
varchar column)

2. The constraints of your object model (e.g., alpha-numeric
characters only in usernames)

3. Application constraints (e.g., usernames that begin with "acme_"
may not be registered using the public web site)

That's all for one piece of information: a username.

Database constraints apply "everywhere."

Object model constraints also might apply everywhere, by you may want
to bend the rules for some special cases.  (If an object model
constraint really does apply everywhere, it should probably be moved
to the database, if possible.)

Application constraints are almost certain to change (e.g., internal
admin tools usually have fewer such constraints than public end-user
tools).

If you try to smoosh up all three of these kinds of constraints into a
single definition, much pain awaits you :)  My preferred distribution
of responsibilities is:

1. Database constraints: defined in the database, and also reflected
(as much as possible) in the ORM-based classes.

2. Object model constraints: defined either in the ORM-based classes
or in classes that wrap them (if such things exist).

3. Application constraints: defined in form/field objects, which may
inspect the ORM constraints and use them as a starting point.

-John



More information about the Catalyst mailing list