技术框架上的皮之不存,毛将焉附

俗话“兵来将挡，水来土掩”
LZ的意思就是“兵来土掩，水来将挡是错的！”

LZ所说的假设只因为他存在所以有框架的存在。
开源框架的存在是为了解决某一领域的问题，看你怎么去取舍？

 

 看了，都很有才！

    非常恭喜楼主，看到这一面，证明你已经成长了许多。做软件的人浮躁的非常多，我记得6年前，我在javaeye的时候看到许多人跟风痛骂EJB，热推Spring；痛骂CMP，热推Hibernate；痛骂Struts,热推WebWork；到后来看到痛骂RUP，热推XP；痛骂Java,热推Ruby等等。许许多多的人根本就没有想过，更加没有思考过他们之间的区别与定位。甚至到后来，更可笑的是一个软件架构师=Struts+Spring+Hibernate了，着实可悲。
    这个世界上绝对没有万能的银弹，也不会有许多人研究推崇的废物，有的只有适合与不适合。就拿EJB说事，到今天，我相信到明天一样会有生命力，否则早在2.1的时候就该死了，被人痛骂的CMP也不会演化成JPA（到头来，Hibernate只是弱化成了JPA1.0的一个实现）。
    一个优秀的软件设计师，一个优秀的软件架构师，是必须要看到这点，做到物尽其用，而不是盲目地跟风。
    楼主看到了假设，看到了前提，更加还要看到它们适合的应用场景，彼此的优缺点。。。

有需求，才有解决方案，一系列的解决方案的精华成就一门技术;技术也会随着需求改变吧.我觉得把握变与不变才是真理.

Hibernate是兼容JPA 1.0，不是弱化。

对这个精华有点失望。



那客户端生成UI的代码哪里生成的？我的理解，RIA增强的是客户端的表现能力，而架构并没变。如果有不同意见，欢迎指教。

tag的目的1是为了分离UI和“java”代码，2是为了封装代码，实现程序员的UI和美工UI的职责分离。即使将来RIA了，还是要分离这个，即使没有JSP的tag，也会有FLEX的tag，来将程序员的UI增强到美工UI里，却不影响美工。


你hibernate和ejb那段我挺赞同，另外不同意你关于spring的看法，spring并没有强调一定要在服务器端，他强调的不过是一种解耦的思想，这种思想很多时候不是通过IOC来体现的。IOC是核心不是一切。 我们不用spring未必就不能用这种思想。

看技术，看前提，我再补充一点，看目的，并且从他的技术实现中学习手段。


最近看grails源代码，了解grails的设计思路，并通过这个过程掌握使用groovy语言的技巧。很有收获：java程序员没必要妄自菲薄，grails这些东西，在技术上，还是用的java的技术，某些部位，使用了groovy来增强。

我很担心grails比ror要差，于是找ror的fans问和比较，伯仲之间，不过ror先入为主了。就能力上groovy语言已经不逊色ruby了。
grails也是有缺点的，这个东西继承自spring和hibernate，并且多数技术都是后者只是用groovy关键部位做了代码增强，因此，很多时候要有后者的技术积累，前者不过是提供了多数情况下的快速开发能力。

优点是：对ssh熟手来说，提供了ssh快速开发框架，多数情况下提高效率，少数情况下——回到ssh，并且将问题和groovy框架混淆。so，要深入了解grails————这都是学习成本（换取开发效率）
——————————————————
貌似javaeye最近精华的水准下降了。我建议是不是有一个“二级选举”：
不同的领域，比如java，或者RIA，或者别的什么，都有“领域专家”以及级别。
这个职称依靠群众投票和个人发帖被推率等综合计算得出。
不同级别的专家，对不同领域的帖子评分，按照对应领域级别估定评分比重。

现在貌似，领域没区分。

看了以上这么多回复，感觉都是从同一个人的角度在看问题，而现实上往往同一个问题的处理者都是不同的角色，这就导致了不同人看问题的不同角度和不同方法了。

领域和实现是不同的东西，往往做设计的是一个人，而实现的又是另外一个人。这就不同保证实现的人能够理解设计人的意图了，或者实现者又有自己的意图，这就导致了冲突的存在。

所以，同一个问题，同一个框架，从不同的使用者角度上，都有不同的意义。高手可能认为解决方案最重要（不是方法），而一般人则认为实现方法最重要，这就从认识层面上把人给分别开来，所以有不同的理解，是很正常的。

我也很赞同LZ的观点，不管是从哪方面来看，而且软件开发并不是从哪一个人就能决定所有的开发方面的。同一个问题，不同人总有不同的解决方案，但前提都是为解决某一类问题而出现的。

没有能够解决所有问题的银弹，所以不可能连问题的假设都没有。

   hibernate当然还存在，可是未来呢？hibernate只是一个开源产品，在商业公司几乎不会被使用，因为没有任何商业支持。
   如果你是一个JEE的系统设计师或架构师，你应该关注的是持久化的行为而不是具体，这就是JPA的空间。JPA作为JEE容器的一部分，任何一个JEE的容器都会提供实现，你丝毫不要去关心它来自于何种的实现，hibernate也好，toplink也好。
   到了JPA2.0，完全的参考实现也已经是EclipseLink(原Toplink)了，hibernate是否支持，也不确定（不过Jboss是估计要跟进的）。
   对于一个业务系统的设计师来说，hibernate与否还有太多的意义么？

一切以市场为导向..
事物的存在 在于 它拥有自身的生存空间

优胜劣汰 物竞天择
大自然的生存法则而已.
生物如此 技术亦如此.