Web 应用中用户录入数据错误检查在分层设计中的定位

按照通常的 Web 分层开发设计模式(MVC)，Web 应用应该分 Web, Service, DAO 三层。

以常见的 Struts 来讲，Web 层包含 Struts Action, JSP, HTML, Javascript, CSS. service 是单独一层，隔离 DAO 实现。 DAO 则是纯粹的数据库访问(增加、修改、删除、查询)。

以笔者项目中所遇到的情况，包括笔者更改别人的项目代码，发现一个普遍的情况是，“用户录入数据错误检查”，被放在了 action 层。这很值得商榷。

“用户录入数据错误检查”，通常包含以下方面：

1. 非空检查，比如新建用户时，用户名不能为空。

2. 字符串长度检查，比如用户名最大长度检查，与数据库设计字段长度保持一致。

3. 日期格式、日期有效性检查。比如不能报销半年以前的出租车费。

4. 逻辑检查。比如一个用户不能报销同一天的出租车费超过 10000 元。

5. 状态检查。比如“订单已经创建，不能重复创建同一个订单”。

前三者，很多人都放在 Web 层，也就是 Struts Action 层中。

然而，仔细想想，以上错误检查，都应该是业务层的东西，这些检查，都应该与用户确认需求，都是非技术的需求。

对于“字符串长度检查”，曾经看到某个系统中，有这样的代码：

if (userNm.getBytes("UTF8").length > 20) {

...

}

其中的 UTF8 是数据库的编码。这样的代码很成问题。

每种字段的字符串长度限制，是纯粹的用户业务需求，不是数据库设计需求。用户需求只可能是：

“用户名中汉字和字母加起来最多20 个字符”，

“用户名中汉字算两个，字母算一个，加起来最多20 个字符”。

用户需求中，不会提到数据库编码是 UTF8 还是 GBK。我们之所以在代码中，检查用户名长度，是因为有明确的用户需求，如果没有用户要求，我们在数据库设计上，可以随便放多长，2000 或者 4000，技术上，都不是问题。

对于用户名的长度检查，

1.新增用户时会用到，

2.修改用户时也会用到(如果你的系统，有“不能修改用户名”这样低级的错误，则需要请一个技术高手好好把这个代码全部审阅一番)。

3. 通常系统中会有另一个功能，通过文件导入 Excel 数据文件，来批量增加新用户，这个地方，也要进行用户名的长度检查。

如果把用户名的长度检查，放在 Web 层，代码的重用性实在是有点为难。要保证以上三个情况，如果用户名长度限制，由 20 统一变成 100, 是否可能漏改其中一个，也很难说。

相反，把用户名的长度检查，放在 service 层，写成一个公共的函数，比如 UserSrv.validateUserNameLen(String userName), 则方便很多。

把这种长度检查放在 Web 层 Struts Action 中完全没有道理。至于放在 client 中，用 Javascript 检查用户录入的用户名长度，那更是胡扯。

我们应该明白一点：如果用户需求中，有要求进行用户名长度检查，则这时一个用户需求，是一个业务逻辑，应该放到 service 层中。如果用户没有要求进行用户名长度检查，则代码中进行用户名长度检查纯粹是多余。

同样的道理，上面提到的其他类型的用户录入数据检查，也都应该放在 service 层中，而不是 web 层中。