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

转自我的 blog,欢迎大家讨论: 
http://blog.csdn.net/jacklondon
.....
按照通常的 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 层中。

这个？对于一些基本的验证，则使用相应的验证框架，对于一些业务上面的业务需求，则在service处理，对于一些页面所特有的验证规则，直接放在页面，有何不可？

何谓基本验证？
非空检查？还是长度检查？
客户端的 Javascript 验证，可以很容易被屏蔽，只要把浏览器的 Javascript 设置关掉就行了。这是一个中学生都能做到的。
为了防止意外，常见的是，客户端的 Javascript 验证和服务器端验证同时进行。但是这样一来，Javascript 验证就显得多余了。

你在说胡话？最讨厌你这种空对空的讨论。如果你这么说，我还不敢用ajax了，因为跨浏览器的问题。

难道你的用户都会把javascript给关掉？不要自己在假想，去问问用户吧。

client验证可以防止服务器过载吧？当然如果用户通过其它手段，例如跳过web直接post数据，server验证就是必须的了。

client验证可以防止服务器过载只能起到一小部分作用。
如果你的服务器依赖这个，那么别人写程序拼命往你服务器提交 form 数据，你的服务器也早瘫痪了。
ajax 用户太幼稚。谁说 ajax 不能跨浏览器？
你能百分之百肯定，你的用户都不会把javascript给关掉？不要自己在假想，问用户他们也可能骗你说我们很乖的。把程序做的健壮一点有什么不好？

客户端检查是在提交服务器前进行本地检查。减轻服务器负担，同时也是提高用户自己的体验。这种检查防君子不防小人。所以也不要认为有了这种检查就安全了。
服务器端检查则是安全检查。防止非法数据进入系统。至于在服务器哪个阶段检查，我认为最理想情况应该由对象自己检查。在Service里写检查代码都应该是不合理的。自己的事情自己干。而且同一个代码也只应该写一次。在Service里到处写，一旦变化，得改多少地方。

封装成 UserSrv.validateUserNameLen(String userName), 一旦变化，也只改这一个地方。怎么会“一旦变化，得改多少地方”？
魔力猫咪说“在Service里写检查代码都应该是不合理的”，那么按照猫咪的说法，在哪里写检查是合理的？