讨论：业务功能是否应该部分由Trigger承担？

目前我负责的项目，使用的架构是：Tapestry3 + Hibernate3 + Spring +Oracle9i + Jboss4.0.4

简单描述一下具体细节：

Tapestry负责页面层，把需要增删改查的数据通过VO传递给Service层，Spring负责拦截Service层的方法接口实现事务管理，Service层调用DAO层，实现数据的增删改查基本操作，并把VO转换为Hibernate的PO，由Spring的拦截机制Commit数据实现持久。

我的想法是：把所有业务逻辑（包括与业务相关的数据校验工作）封装到ServiceImpl的方法中，只把Service的业务接口暴露给Tapestry，Tapestry调用Service的业务接口，向其传递“合格”的VO数据，这样做，既可以实现业务封装，也可以通过Spring保证事务隔离。

但由于我是中途成为项目的负责人，而且组员也更换了不少，组员的水平参次不齐，有些人为了方便，把很多关联数据的更新操作放到数据库的Trigger中完成，其实这样做也能完成业务要求，也能保证事务隔离，但个人感觉是，这样做的话，业务逻辑就分布于Servcie业务逻辑层与数据库持久层了，而且太多Trigger的使用，会由于开发人员的不严谨，导致一些不符合业务要求的逻辑触发了触发器，导致数据错误，而且这种错误难于发现，而且这样做，也严重不利于系统各层之间的更换和移植，加大了整个系统各层之间的耦合。系统也会显得比较凌乱。

本人从事开发工作只有不到一年，由于比较幸运和上手比较快才做了一个不大不小的项目的负责人，但本人还是比较缺乏经验，觉得数据库的存储过程、触发器既然存在，就有其实在意义，而且把一些数据操作放到存储过程、触发器去实现，也有利于事务隔离和减少WebServer的负担，所以提出这样的讨论话题，希望各位给些意见，应该在什么时候使用数据库的存储过程、触发器，如何保证这个使用的“度”。谢谢。

存储过程我现在仍然在用，但是这几年是坚决不用触发器来实现部分的业务逻辑（当然某些跨系统的数据同步还是用到了触发器，但这个与业务逻辑无关）。
触发器的最大问题是一般它作为更新操作的副作用而出现的，很容易使更新操作的调用者并没有意识到这个副作用，这个和存储过程不同，存储过程的调用几乎都是直接主动的. 另外一点，用了触发器，orm这一层的缓存处理会变得复杂。

trigger概念相当于interceptor，如果说trigger有这个问题，那么interceptor也存在这个问题，甚至于AOP都有这个问题。

不用trigger的最大理由是要保证逻辑控制尽量都在java程序中。部署的时候简单些。至于sp，大多是基于性能考量下的。

trigger和sp都一样会给orm的缓存带来麻烦的.

对于这一句话，我想我不能很好理解，能否举例，简单说说呢？

简单，orm的cache有a对象， trigger或者sp在数据库中改了a的属性propertyA，这个时候orm是不知道的，这个时候orm的cache是不对的。

目前对Hibernate的Cache机制不太清楚（Hibernate学习中...），请问Cache中的东西在什么情况下才会更新？

另：sp是代表什么？Spring？还是存储过程？