fnet
2011-03-27 10:47

感谢banq。

还有一个问题想请教。

对于校验,以前用struts时,我们都是用FormBean校验,或者Common-Validator配置文件的方式。

我们现在将校验放在模型里,使用Hibernate Validator的方式。

校验至少分为以下几种:

客户端输入校验,主要是js,html限制长度。

服务器端输入校验,同客户端输入校验。一般放在controller层

业务数据校验,涉及业务方面,可能与持久层交互。一般放在controller层或service层。

客户端校验不用说。

服务器端校验,我们现在主要使用Hibernate validator方式。

业务数据校验,我们有没有必要放在模型中。还是与模型独立开。

我觉得既然我们发起一个业务操作是针对业务模型。那么是否可以理解为,模型可以自己完成校验过程。

说的不是很清晰,请您见谅。请您多多指教,非常感谢。

fnet
2011-03-27 11:08

比如像这样的校验

public boolean validateAreaid(WebErrors errors

, AreaManager areaManager, Long areaid) {

if (areaid == null) {

errors.addErrorString("地区不能为空");

return false;

}

Area area = areaManager.get(Area.class, areaid);

if (area == null) {

errors.addErrorString("地区不存在");

return false;

}

return true;

}

banq
2011-03-27 13:35

分清楚是业务校验,还是数据录入普通校验,所谓业务校验就是违背业务一致性原则的校验,比如订单中一个条目价格修改了,那么订单总价格肯定修改,这种一致性就必须在模型中完成,可见DDD一书中订单案例,如果价格总是变,可设定价格为值对象。

象你举例的几个都是逐项校验,不涉及太多业务检查,可放到表现层如formBean中,如果你把Hibernate的模型看成是领域模型,也没有必要放在领域模型,如果你把Hibernate的模型看成是持久层校验,放入其中倒是可以的。

反正,必须搞清楚我们说的DDD领域模型虽然可以用Hibernate的对象模型暂时替代,但是不会很优雅,在我的JiveJdon中,这两者是分离的,领域模型纯粹生存在内存中In-memeory,否则,两者混在一起,领域模型内部设计包括方法都要考虑到Hibernate持久化,造成技术限制业务,这和数据库技术限制业务就没太大区别,50步和100步的区别而已。

业务应该凌驾技术至上,技术不应该限制业务,这是原则。公仆不能凌驾于主人之上,只有在人类社会才可能颠倒过来,这技术世界千万别将错就错了。

2Go 上一页 1 2