论Java WEB应用中最基本的单表增删改查的实现和及相关错误模式

个人感觉，现在通常人们讨论和实现Java WEB应用时，往往过度关注框架和平台，对常见实现的各种模式未有深入的考虑。
自从在IBM DevelopWork上见到一个名词"错误模式"，就一直仔细研究和收集各种错误模式，现在就针对各WEB应用中最常见的增删改查，谈一下常碰到的错误模式。

增加、编辑时常见错误
1、没有进行，界面上的效验问题
有人认为，这个不算错误，呵呵，那我也不说什么了。
很多情况下，初学的人会完全忽略这一块，刚开始我就是的，寒
感觉这个就像程序把门的第一关口啊，最好能提前预防。
一般情况下，都是用javascript直接实现的，也有基于框架的后台验证，如DotNet和WebWork的验证器等。通用的方法，是充分发挥正则验证的潜力来解决好这一块。

2、后台效验问题 JS+RPC OR Server
前台的效验完毕后，往往还需要进行后台的逻辑效验，如检查是否重名等。
一般是通过一组查询来实现的。因为只是只读的查询，个人认为，怎么实现都没关系。
通常是在后台，提交数据库前验证。其实业可以通过ajax技术，在前台验证，随着技术的发展，我想还是通过AJAX统一到前台实现比较一致。

3、更新失败返回问题
更新失败的因素是多方面的，如数据连接断开等。往往，很多人都没有进行相关的保护，没有相应的提示，或者提示返回后，客户的输入就丢失了。这些都是应该仔细考虑并解决的问题，很可惜，再大量学习各类框架和平台后，相信很多人都没有仔细的在这一块加上那怕一点点保护。

4、编辑载入失败返回问题
这个是个比较初级的问题，不过确实出现过，还是写写，看看自己忘了不.....

5、编辑载入，值还原问题，如回车丢失，空格丢失等
有时候，Html标签写的不好的时候，可能会丢值，如 回车，空格 ，<等符号

6、更新时，多步操作的事务保护机制不健全
这一点，本不该写在此处，不过，我一直觉得这是个很重要的问题，所以还是加上。也许有人会说，我用Hibernate，这个问题就不存在了.....还是要重视啊，我见过有初学者，没有很好的利用Hibernate的声明事务标签，或者根本不声明...... 而且多步操作不写在一个方法里面，也不用手工的事务控制...寒，其实有些项目我自己都没做到，因为各方面的原因@%^@#^@#^@^,悲哀ing.....

删除常见错误
1、找不到记录时错误
这个是个比较初级的问题，不过确实出现过，还是写写，看看自己忘了不.....

2、关联数据不能自动检查并返回信息
对于一些有关联的数据，应该通过检查机制保护破坏性的删除操作。

3、自动删除关联数据
这个对于一些POJO设计得非常好的系统，完全不用考虑的，呵呵不过，大家还是要很清晰的了解这种删除的必要性，感觉初学者都忽略这些问题。

4、删除时没有清晰提示
通过JS保护只有一行代码，就可以给客户一个避免错误操作的机会，何乐而不为呢,用框架的同仁们，你们这么做了吗？实际的系统，用户不会忘了提这一点的。

查看时错误
1、找不到数据时错误
这个是个比较初级的问题，不过确实出现过，还是写写，看看自己忘了不.....

2、一些值得显示问题 如 回车、空格
加几行转码的函数就可以避免，很多人忽略了，寒，如回车转为<BR>,空格转为  

3、下拉表单数据的回显问题 值－名对，显示值，而不显示名
下拉表单输入时，大家都有解决方案了，回显，就是一个查询，请加上吧，不要让自己眼睛不舒服。

分页浏览时错误
1、找不到数据时的正确返回
这个是个比较初级的问题，不过确实出现过，还是写写，看看自己忘了不.....

2、翻页后 条件保持问题（特别时有特殊字符时，如回车,"/"","/'"等）
要把条件传递到下一个页面阿....

3、翻页的效率问题
很多人没仔细考虑，比如我自己，刚用Hibernate时，直接用一个完全查询的HQL,取List.Count解决取总记录的方法，结果，发现，这个查询被执行了！！！现在改成一个专门取总行数的Count查询...当然用专门对数据库优化过的SQL和存储过程，永远是效率最高的方法

查询时错误
1、查询条件初始化问题
查询条件如日期等，为什么不给客户一个最常用的时间段呢，可以避免用户的操作

其实还有很多需要注意的细节容易出问题。如格式验证...只读字段的控制.等等

一个完整的增删改查应该有几个部分的代码
1.添加载入
控制添加数据的默认初始化值
在Struct或者WebWork中，就是一个Action +一个视图

2.添加提交
将用户提交的新增数据，加入数据库
在Struct或者WebWork中，就是一个Action

3.编辑载入
从库中载入已有的某条数据方便编辑
在Struct或者WebWork中，就是一个Action +一个视图

4.编辑提交
将用户提交的修改数据，更新到库中
在Struct或者WebWork中，就是一个Action

5.查看记录
从库中载入已有的某条数据查看

在Struct或者WebWork中，就是一个Action +一个视图

6.删除提交
将用户指定的记录删除

在Struct或者WebWork中，就是一个Action

7.载入查询

初始化查询界面

在Struct或者WebWork中，就是一个Action+一个View

8.查询提交
接受查询界面的提交，并组合为查询结果发送给一个View

在Struct或者WebWork中，就是一个Action+一个View
也可以将请求转交给分页浏览页面

9.分页浏览
根据查询条件和页号，显示特定数据页的数据

在Struct或者WebWork中，就是一个Action+一个View

这里，我没有专门写出formBean，个人认为FormBean只是一个工具
当然根据情况各种Action 和View可以进行各种整合，不过个人觉得，不管如何组合，这几个环节都是很必要的，必须思路非常清晰才好。

附上我以前总结的一些常见的错误检查表，给同事看的...
******************************************************************************************************
JAVA WEB应用常见的错误
在本系统中一些常见Bug和对策

1.Null指针错误

A.引用的Bean未在 Hibernate配置文件,Spring配置文件中正确的配置

B.调用的Session及Request 未能正确的取到

C.对象未初始化，或者在传递中失去了，往往使webWork托管的对象出现这种问题

D.未正确的写上Getter,Setter方法

2.无任何提示的错误...
A.一般情况是HibernatePO执行的时候发生的错误,未将错误正确的抛出..

B.转入Error页面采用Redirect模式，错误信息不能显示

其他
A.WebWork Action中未找到对应的映射

B.在弹出窗口中,Session丢失

C.Tomcat,MYSQL乱码问题
在WebWork值得注意的是URL传递的参数，需要手工用toCN转码
Form传递的不需要

D.WebWork标签的引用问题,Map request并不是和request映射的那个对象
有一个同名对象，但是类型是httpRequest的Request才是..

E.Hibernate查询书写出错

F.Delete方法使用出错

G.验证器使用出错

H.类型格式定义不正确..如日期时间型显示为日期型

I.在WebWork的JavaScript中，好像不好直接使用'和"符号,也许要HtmlEncode后，才能用？？，还是要UrlEncode?

J.全角作主键时，传递异常...

K.JS 调试的时候，层次关系中，<!--注释-->也是一个子对象..

L.验证实现不精确..

M.再次注意，空值的包装问题，再webWork中自动处理了，用其他框架时，要充分考虑

N.JDO对象需要及时更新，并且要及时调整相关的Bean

O.缺少JDO请及时加上

1.纯JSP编写时发生的错误
一般是没有正确编译，将编译中的Java文件放到IDE中编译一下，就可以看到提示.
******************************************************************************************************

1、对Null字符进行String处理出错
产生原因:数据库中数据为空值，却用字符处理函数进行处理了
后果：崩溃性错误
预防方法：
A.给数据库中可能出现空值的字段，加上默认值
B.提交时，用JS脚本进行验证
C.在处理可能是空值的字符时，用CheckNullStr(vValue) 对数值进行保护处理
D.对处理过程加上错误陷阱，防止出现崩溃性错误

2、传递参数时，" ' 等字符造成问题
产生原因：处理" '等字符时，和Html中使用 " ' 等冲突，造成数据传送失败
后果：崩溃性错误
预防方法：
A.统一" '等符号的使用模式和策略
　　　　　　如 JS中，字符串用""包起来 '　需要用　/'代替
　　 　　如传递查询参数时，其中可能有 ' 和 % 需要特别的处理，所以用""包字符串
B.在不丢失数据的情况下，根据情况使用
Server.HtmlEncode(vValue)
Server.UrlEncode(vValue)
C.对处理过程加上错误陷阱，防止出现崩溃性错误

3、数据库里面未设置主健
产生原因：构建数据库时，未设置主健，
后果：造成查询时,RecordCount显示不正常，更新时得不到主健值，造成崩溃性错误
预防方法：
　　　　 A.建表时仔细检查主健是否建立，如没有一定要建立
B.对处理过程加上错误陷阱，防止出现崩溃性错误

4、数据库里面字段范围设置太小
产生原因：字段设置太小
后果：如发生越界情况，就造成崩溃性错误
预防方法：
A.仔细考虑字段大小设置,如不是很密集的应用，可考虑尽量设置大一些
B.对处理过程加上错误陷阱，防止出现崩溃性错误

5、处理各个模块,因为Copy 代码,所以显示的某些提示不准确
如工作邮件，提示为工作任务等
产生原因：硬编码，Copy代码，粗心大意
后果：用户感觉极差
预防方法：
A.仔细检查,利用全文查找,Windows的功能就可以，还可以用FrontPage
B.尽量使用一些比较模糊的提示语，可以具有通用性
C.将某些特定的提示进行常量定义，统一替换
　　　　　

6、单位名称等不匹配
产生原因：硬编码，Copy代码，粗心大意
后果：用户感觉极差
预防方法：
A.仔细检查,利用全文查找,Windows的功能就可以，还可以用FrontPage
B.对使用的特定图片检查
C.将特定图片和文字进行登记
C.将某些特定的名称进行常量定义，统一替换，尽量利用Customer等通用常量，避免硬编码