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 层中。



------解决方案--------------------

探讨

客户端的 Javascript 验证，可以很容易被屏蔽，只要把浏览器的 Javascript 设置关掉就行了。这是一个中学生都能做到的。
总体来说，客户端的 Javascript 验证，纯粹是搞笑。为了防止意外，常见的是，客户端的 Javascript 验证和服务器端验证同时进行。但是这样一来，Javascript 验证就显得多余了。

------解决方案--------------------
同意楼上的.js从来都不会多余,即使你服务器端有验证,但是如果你能把一些验证放在客户端的话就能避免一些很明显的错误的发生,而不会让用户反复的进行输入,提高用户感受,建议楼主研究下ajax吧,不知道现在这东西挺火的吗?知道还敢鄙视js?
------解决方案--------------------
我觉得单纯从客户端通过JS来检查这种做法是有欠缺的，这点是肯定的。。
但是我不觉得多余，至于说到代码的繁琐，我们可以把JS代码放到XML文件中进行管理，这样就不至于改一个属性限制要改很多文件的事发生了
同时服务器端也要做验证，结合起来我觉得才是合理的，不存在搞笑不搞笑的，而且速度与效率的问题。
------解决方案--------------------
知不知道什么是用户感受啊,在现有的网络环境下,如果能减少不必要的重复提交及等待那是非常重要的,你真的准备做这方面的工作还是来搞笑的