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 _______________________________________________ List: [email protected] Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[email protected]/ Dev site: http://dev.catalyst.perl.org/
