一个友好的应用应该提供给用户明确的信息提示,比如说“用户名已经存在” “用户名过长”.....
这些信息根源于数据库中设计的各种约束。当操作出发这些约束的时候,会得到一个spring包装起来的dataAccessException异常。我现在的做法是在dao包用了一个pointcut,织入了after-throwing通知,打算重新抛一个自定义的异常给业务层。
但是现在的问题是,不知道怎么去细分dataAccessException,只能用ex.getRootCause()得到一些信息。

解决方案 »

  1.   

    其实像用户名过长等,可以在前期就处理掉,而不用到DAO层
    这些检查是有必要的,可以防止注入式攻击,包括有效字符,长度等像楼主的需求,可以分析一下rootcause,抽象出某几个业务层的信息就可以了,其他的可以可以归为一类
      

  2.   

    在jsp页面用ajax请求校验,这样可以减少没有必要的提交次数
      

  3.   

    楼主的解决方案好像并不能通过Exception对象来抛“用户名已经存在” “用户名过长”.....这些信息,除非手动地在aop中判断字符串大小,并throw一个Exception对象,这样是不是觉得有点死板?因为aop横向切面方式面积整个系统,而不是针对某个字段。如果抛开楼上几位在web层解决方案的话,我觉得在逻辑层有两种方案尚佳:
    1、用Hibernate验证,例如:@Length(max=30,message="用户名最多只能为30个字符")
    private String username;然后可用以下这个方法来检测实体:
    ClassValidator<T> cv = new ClassValidator(clazz);
    InvalidValue[] message = cv.getInvalidValues(t);
    if(message.length > 0){
    for(InvalidValue iv : message){
    //iv.getPropertyPath()为出错的属性
    //iv.getMessage());为该属性出错的消息
    }
    }
       }
    通过Hibernate事件也可以检测JDBC反馈消息,例如不能插入重复值。2、用楼主所说的AOP方案
    但最好也参考Hibernate的验证思想,即在实体上用注解的方式(或xml)来标定每个属性的长度、唯一性、数据库类型等等。@valid(length={30,"长度不能超过30"},unique={true,"用户名必须唯一"})
    private String username;然后在aop的point中拦截要被保存或更新的实体,用内省和反射来检测每个属性配置的长度并抛错,其实是和Hibernate验证是一个道理,无非这样好控制一些,例如可以控制到数据进入数据库时发生的错误——用户名重复等等