关于开发效率和性能的选择

开发效率和性能总是死敌。
一个技术，基本上要么开发效率低下但性能超好，或者开发效率提高但性能下降了。
je上最近的2个帖子，其实都是在讨论一个问题，到底是性能优先还是易用性优先。（rpc or norpc,hibernate or jdbc)
我看到很多人都选择性能优先。
其实这个问题很简单，选择性能优先的选择norpc,jdbc,甚至存储过程。
倾向开发效率的人往往选择rpc，hibernate。
同类的选择还有stateless or stateful.spring的作者rod johnson一开始也曾鄙视stateful ejb,理由是性能太差。不过后来他也承认stateful ejb有其合适的用途。

另外一个类似的例子是web层的状态管理。如今的大多数基于jsp的mvc都是无状态的。但hibernate的作者却提出要让web层有状态。他搞了web beans规范，推出了seam产品。
显然，seam的一个目的就是通过新增的状态管理，简化web的开发。然而，同时他也指出，seam适合小型的相对简单的项目。

我的结论就是，每种技术都是双刃剑，作为程序员，尤其是架构师，要根据情况，选择合适的技术。不能简单的说那种技术好还是不好，而是得有上下文。
不能盲目的追求性能，
舍弃hibernate，舍弃stateful session bean,舍弃web service，
而选择jdbc, 存储过程，stateless session bean, socket.

对于性能，在满足需求的前提下，就应该追逐开发效率。否则你连java也不要用了，直接写汇编去吧。
不见得每一个系统都有庞大的用户群。我相信绝大多数的系统都是中小型的系统，绝对有理由牺牲部分多余的性能换来开发的简化。
更何况就算是一个庞大的系统，正因为其庞大，也不必只选择单一的技术。比如客户访问的模块因为人多，考虑性能而选择jdbc。
但管理模块则考虑整个系统就几个管理员使用，可以选择hibernate。

赞同你的观点，呵呵

MVC也可以有状态。性能好坏不取决于你选择的技术框架或者类包。性能更倾向于你系统的压力与你系统的设计。用ORM不代表性能就比JDBC差。

赞同楼主的意见，除非需求调研中客户极大的关注性能问题，否则应该是开发效率第一。

至少在目前大部分J2EE项目中，性能问题还不是首要考虑的因素。

没有最好的，只有最合适的

一个技术，基本上要么开发效率低下但性能超好，或者开发效率提高但性能下降了。

-----
这话是什么逻辑。。。

舍弃norpc，选择rpc，不见得性能就会低下，要看你选的rpc是什么方案，如果选择webservice，那肯定是性能低下的。如果选择hprose，性能反而会提升，开发效率也会大大提升。

选则开发效率+集群
证明了公司对开发人员价值的肯定
要是程序员工作没几个钱。。。。

我问一下，大家有没有用过ejb的，这东西在性能上应该没什么优势，为什么sun现在的oracle还在发展它？现在有什么大型的东西是用ejb搞出来的吗？

性能可以在很多地方进行优化，但是效率却是另外一个层面的问题了，可能一个项目组的boss会很在意效率问题，至于性能问题，是需要在应用中发现了性能问题之后，才进行优化的