技术架构问题！

反对用Hibernate，如果大访问量的话，会有非常专业的DBA来对SQL优化，如果用Hibernate，优化很难的

有时间的话可以研究Hibernate，但是它只能作为一个高效的sql生成器，并不能减少什么屏蔽sql的作用，要成为Hibernate高手，sql就不能太差，要知道什么业务操作会产生什么样的sql，执行效率如何。

但是一旦成形了，后期效率会非常高。

要想真正提高性能，要根据业务，进行精确的缓存架构设计和应用，缓存架构可以是一种或多种形式的组合，既可以利用持久层的缓存，也可以利用前台的memcached，也可以考虑JVM级的对象级缓存。

用第一个方案吧， 第二种确实事务控制是个头痛的问题。

如果开发组中没有对hibernate非常熟的人员，还是慎用为好。

楼上正解 亲身经历过这种痛苦
慎用

一般业务系统开发而论，ssh还是王道的。

hibernate的确不错，但在实际工作中真正懂hibernate并且会用hibernate的极少，
别说高层次的"优化"了,就是那些看起来普通的增删改查,都充满了陷阱。
可能是懂的人不用，用的人不懂的缘故吧

我看见有人把缓存放在application中，请问这样有什么弊病?

web中的application缓存，没有什么明显的弊病。

我认为的弊病是，在不是大规模使用的前提下，web缓存不利于测试，JVM级的缓存测试方便。

还有就是复用的问题，数据的消费者未必是web啊，也有可能是webservice对不对，这样的话webservice就不能用到web缓存了。

还有就是你的控制力度的问题了，web缓存的话意味着你控制的是处在web这一层的对象，比如页面显示信息和DTO等，你的manager和service要直接利用这个缓存也会很麻烦，估计也不会利用。当然如果web缓存用得好的话，其他层的缓存也未必要用了。

不同场合不同结论，给定应用场合比较好举例。

技术选型要关注的点很多，单从你贴子上的“需求”描述就给你一个定论或者建议的话，估计太悬了。
网站主要的业务是什么？主要提供哪方面的功能？对数据库的操作是写多还是读多？开发周期仅3个月，那这10多个开发人员对需求的了解如何？这些开发人员的技术取向及程度如何呢？等等这些都是一些决定性因素。
话又说回来，因为开发周期很短，所以应该选一些比较定型的稳定的开发框架，比如spring hibernate等等，当然这也看使用的熟练程度上。其实如果前面有积累的话，建议你用前面积累的东西，因为这是赶项目的一个捷径，而如果时间宽些的话，可以使用些虽然不熟但比较良好的技术。
个人观点的唠叨一句：其实好的技术在于：不一定使用得很好的人才能使用好它，因为它的默认或者说简单就可以满足大部分的需求了。：）