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

2008-05-04 14:24

 

按照通常的 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 层中。


 
		

 

 

欢迎转载,转载请注明出处: https://www.zheguisoft.com/staff_blogs/jacklondon_chen/2008, 及 https://blog.csdn.net/jacklondon/article/details/2382120?spm=1001.2014.3001.5501