是否应该在 DAO 中强制执行特定于数据源的限制？答案

【问题标题】：Should datasource-specific restrictions be enforced in DAOs?是否应该在 DAO 中强制执行特定于数据源的限制？
【发布时间】：2013-03-23 20:26:49
【问题描述】：

对于强制执行特定于数据源的限制，是否有任何推荐的做法？

例如，当保存的String 超过255 or 65535 limit given in MySQL documentation 时，有一个断言或抛出一个异常。还是应该由数据源处理？

http://dev.mysql.com/doc/refman/5.0/en/char.html

VARCHAR 列中的值是可变长度字符串。长度可以在 MySQL 5.0.3 之前被指定为 0 到 255 之间的值，以及 0 到 5.0.3 及更高版本中为 65,535。有效最大长度 MySQL 5.0.3 及更高版本中的 VARCHAR 受最大行大小限制（65,535 字节，所有列共享）和字符设置使用。请参阅第 E.7.4 节，“表列数和行数的限制大小”。

【问题讨论】：

标签： java mysql constraints dao

【解决方案1】：

在您的数据访问层内，您应该进行的唯一验证是为您的特定数据库架构定义的验证。您可以将数据访问层视为架构的对象表示，它应该尽可能地模仿架构的结构、数据类型和约束，仅此而已。所以，给定以下简单的模式：

CREATE TABLE `users` (
    `id` INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    `user_name` VARCHAR(64) NOT NULL,
    `passwordHash` VARCHAR(256) NOT NULL,
) ENGINE=InnoDB, DEFAULT CHARACTER SET utf8;

您将在数据访问层验证：

userName属性在保存前设置，为长度小于等于64个字符的字符序列
passwordHash属性在保存前设置，为长度小于等于256个字符的字符序列

但是，非常重要的是，您应该严格避免仅与特定数据库实现相关的任何检查。首先，您希望您的数据访问层与提供者无关，其次，大多数供应商特定的限制会在您尝试创建表的那一刻触发。

【讨论】：