如果你有一个ＶＩＥＷ中涉及多个表的字段，是不是先在数据库建好一个视图，然后再建一个ＤＡＯ，还有关于这个视图中字段的ＶＯ，实现ＯＲＭ呢？

　

不用视图吧，如果你打算采用ORM，我觉得可以把视图功能放在ORM框架中完成--事实上：也许是我技术不过关，或许是当时Hibernate的确不支持MySql的视图，我以前死活都不能VO在MySQL中的视图。所以后来就一直用ORM框架搞定。

另外，说说不用视图的好处：灵活的业务逻辑
比如说我昨天遍历循环帖子的时候之用显示帖子作者的名字，并不要求性别。好，那我在视图中就定义了AUTHOR_USERNAME字段。
可是今天老板竟然要求性别也要显示出来。天，难道又要我改数据库？

我的感觉就是，尽量用ORM框架去管理数据库中的 事务、级联、触发器、视图，这样ORM框架能够第一时间感知低层数据的变化，能最大限度的利用Hibernate的缓存机制。否则在低层的数据由于触发器而改变了，但是Hibernate并不感知到(事实上根本没法感知)，那么就会造成脏读(缓存内容和实际内容不一致)。

顺便说说，现在ORM框架推出了标准了，JPA，也许你也听说了，从Hibernate3.2开始，Hibernate就正式的获得了JPA认证，从而成为开源的JPA标准实现。

嗯，了解了，也就是说在数据库中的那些事务、级联、触发器、视图是不需要你在创建ＤＢ的时候创建的，而是到ＯＲＭ框架中完成的！

这是我的理解，不一定保证正确

嗯，我也刚学．先这样理解吧．谢了，大虫！