Java 框架到底怎么了？

如果你作为一个 Java  程序员从事 Java EE 开发的话，你一定会使用到众多应用程序框架。没有任何一个语言会象 java  语言社区那样活跃，任何一种新的程序理念都会很快在网上出现相应的开源实现。对应最常用的网站开发模式ＭＶＣ，每一层都会有很多框架，Struts, Tapestry属于控制器层（C），  Velocity  框架属于视图层(V),  你使用的数据持久层可能是  Hibernate,iBatis,  OJB,  或者是  JDO  的众多开源实现中的任何一个，比如  JPOX  。  但是你的选择太多，未必是件好事，并不是任何人都能采用正确的框架来做正确的事情。

如果你的开发平台是  .net，  那么你也许会避免这种情况，通常你只要安装一个  Visual Studio .net  作为开发工具，然后安装一个  MSDN  来查找资料就可以了。

 

对于程序开发人员来说，这是非常两难的事情。我本人很喜欢  Java  ，无论是学习还是实践，它的确给我们提供了很多。但是为什么我觉得  .net  那样“一站式”解决方案在很多时候是正确的呢？

 

作为一个 Java  程序员，我觉得 Java 一些比较明显的问题，首先是 Java  太复杂，其次 Java  太面向程序员了，而不是面向用户。相对  Ｃ++  来说，  Java  已经很简单了。现在 Java  程序员数量如此多就说明了这点。但是正如有人曾经说过的那样，“在 linux  上，你很容易区分出谁是高手”，在  Java  领域中就不那么容易了。我就经常发现身边的同事还在犯很低级的概念性错误，他们甚至在无法准确地区分什么是接口，抽象类和  Servlet 的情况下仍然可以从事多年的 Java EE  开发。但为什么又说  Java  复杂呢，因为它完成一件事情，需要太多不同的技术来实现了。这样对于那些概念不很清楚的程序员来说，你如何能保证他们作出正确的选择呢？而众多框架中有没有多少提供“一站式”服务的。最近冒头的  Spring  框架提供的服务在众多的框架中算是最多的了，但是它又有个新问题，就是它还是太面向程序员了，而不是用户。为什么这么说呢？框架本来就是面向程序员的，这难道不对吗？Spring  虽然提供了众多选择(但是还是不够多，它本身没有 ORM )，但它没有提供简单的使用方式，所以我们只能说它是面向程序员的。绝大多数 Java 框架都存在这个问题，就是学习曲线比较高。

 

我觉得学习曲线的高低是区分一个框架是否是面向程序员还是用户的关键，我想这主要表现在框架的易用性上。其实框架最终的用户还是程序员，之所以用“用户”和“程序员”来区分，是因为一些面向“程序员”的框架比较难以使用，虽然提供了大量的基础设施和零件，但是还是要求程序员自己来组装。而面向“用户”的框架就简单一些，用户只要按照说明书来使用就可以了。

 

为什么  Ruby  on  rails  会在  Java  社区引发轰动，我想原因就在于此，它提供了一个“一站式”面向用户的简单易用的框架，这是  java  框架所缺乏的。

 

 

                                                                                                                                        ——摘自《Ruby on Rails 实践》