Defense in Depth vs. DRY

The principle of "defense in depth" states that constraints should be enforced in multiple places, so that if a piece of data bypasses or slips through one layer, it is caught in the next. A good example is in a web app - you put validation in the client side javascript, in the server-side code (PHP/Ruby/ASP/whatever), and you put those rules in the database (e.g. foreign key constraints). That way, any data that gets past the Javascript validation gets caught by the server side. Any data that gets past the server validation is caught by database constraints.

However, this seems to violate the DRY (Don't Repeat Yourself) principle. Here you've got three places where the same validation rules are being repeated. I understand that there are ways to generate client side javascript such that it enforc开发者_Go百科es server-side validation. My question is, how does one consolidate database constraints and server-side code? Is there any way to generate code such that it automatically enforces database constraints?

We've done this by making a single module the owner of the "security rules", then creating an AJAX interface for it as well, so that the server-side code calls it directly, then front-end UI components call the AJAX interface, but they're all talking to the same module. In this manner, the access rules are only ever in one place (the security module) and you still enforce the rules everywhere. This has an extra advantage of keeping the rules outside of the client-downloadable code.

DRY (Don't Repeat Yourself) is a source code, best-practices principle that basically means: do not duplicate code because if you do you'll lower maintainability and increase the chance for bugs.

Enforcing referential integrity in the database is not a real violation of DRY because:

• a database is not part of the source code
• stands on its own
• can be accessed and modified many other ways besides the client-side view. E.g. querying and reporting engines