我没有太高的水平，但是如果我一定要用现在的框架吗？

你所谓的使用框架带来的风险只是相对于你个人而言。因为你是现学现用的。肯定有些东西用不到刀口上。但是如果你不学的话你就不会用。当然就不会带来你所谓的风险。。当然如果你认为你不需要进步的话。。
并不是说使用框架没有风险。这个我也不敢说。刚刚学，呵呵。。
还有就是框架和设计模式的作用是使可重用。除非你想写个一次性的东西。 或者只有你一个人能维护的东西。哎呀。。这个东西是越说越多了。比如你设计一个四个插孔的插座，可市场上最多的也就三个插孔。。人家还要你的东西啊。

如果大家碰到这个问题。

一般是采用现学现用还是走传统路线呢？

1.不使用一样可以设计出可靠的系统，当你完成这样可靠系统时，你会发现你实际上花费了很多时间在开发类似这些框架的功能代码。

也就是说，不使用可以减少学习成本和用新框架带来的风险，如果你又需要达到这些框架组成系统的高质量，你肯定需要花费更多时间，一般情况下是以质量损失为代价的，也就是说，你只能设计出比较可靠的系统。
这是质量和快速方面的权衡，逃避不了。

这些框架基本在性能 稳定性 可维护性 可拓展性方面对你有帮助，至于开发效率方面是仁者见仁，本站也有很多讨论。

多谢banq的指导，现在的框架太多了，真不知道它们哪个适应我们的业务。

再问一下，对于社区类的这一些应用，权限控制比较复杂。业务对象相对来说也比较多。一个请求里要处理的逻辑也比较多。用spring+hibernate+struts的组合是否适合。

而且他们对群集的支持是否够理想呢。

>社区类的这一些应用
社区类应用表面很简单，其实相当复杂，一个好的真正有创意的社区软件并不比ERP简单，社区对实时性要求比企业软件要更高，类似游戏软件，所以社区类软件应用是游戏+企业总和。

所以，社区类软件更多是依靠自己创新，没有现成的模式架构可迅速套用的。

不会框架并没有什么啊
得根据实际情况（工期）和自己的能力水平来看，能力水平强的话，作出来的框架也许比老外的强得多，工期短的话，劝你还是用吧，这样会节省很多时间出来（当然性能就差得很了）

先用Struts＋Spring吧。Hibernate虽好，但却是那种看起来容易用起来很讲究的DD，弄不好反而添乱。Spring的JdbcTemplate把JDBC封装的很好，节省你很多代码。用Spring你只需要分清singleton和none singleton就可以了。