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

啊呀，楼上言语正好被我碰到，硬件DIY和装修实际上是有一点点像的，遗憾工程啊。

自己对自己配的硬件的感觉是很主观的，并不很可观的。。。省略1万字。

回过头来说，软件框架一样如此，框架在正式发布那一个时刻起，就变成其他新技术赶超的目标和对象，被赶超是很正常的，但是回过头来说此技术或框架如何如何不好没用就是心态不好了，每个人都有质疑的权利，但是不能轻易下结论，质疑的同时最好提出解决方案，否则也是空谈而已。

如果技术如一潭死水（如被微软垄断）那才叫没意思呢。

这句话比较经典      对未来的预见性   是很大的利益增长点的存在的基础

楼主这篇文章写得很好，给盲目追求技术的人眼睛擦亮了。

PHP 也可以直接用 对象 mysql_fetch_object 就是。
Java 无法直接像动态语言那样用对象，才会有做专门的映射。在PHP上再发明 iBATIS 之类的软件肯定是再做轮子。

Hibernate 发明 HQL 的用意之一也许就是 兼容数据库。

嗯，我承认用 Hibernate 可以轻易的由 MySQL 迁移到 Oracle 或 SQL server 。
迁移数据库又是一个很大的话题了。

PHP高手多喜欢用数组不是因为不知道对象吧，是出于性能考虑吧。

你说Java无法像动态语言那样，问题是PHP是动态语言么？动态语言的动态性是有代价的，例如降低编译期的约束检查、降低代码可读性、一定程度增大模块间的耦合性、掌握程度火候不够的程序员更容易写出糟糕的代码等。

我不认为HQL最大的用途是兼容数据库，因为大多数项目是不会换数据库的，即使不考虑数据库兼容，我还是会喜欢用HQL，而不是直接用SQL。你如果深入了解HQL的使用，以及Hibernate相关的配套体系就能体会一二，Hibernate绝对不是大家想的那样封闭，反而是最开放的，想怎么玩都可以。

的确，人作为设计者的参与非常的重要，在客户真实需求和技术手段之间，需要有人来参与做设计。框架可能是不错的工具，但是，设计本身是一定要有人来做的。根据设计的结论再来确定技术选型。

不同的人，考虑不同的问题。如果是老板，考虑利润是可以理解的；但是，如果你是来做项目的（项目经理、架构师、程序员。。。），就应当考虑适用性的问题，这是第一位的。最后，在各种需求之间做平衡。

我想说的是技术只能解决某些问题，或某些难题，但是不能解决全部问题。我认为某种技术只是解决某类问题的一种方法，并把这种方法封装成组件。

不见得吧，java体现的是面向对象，封装的概念。很多东西都封装好了，你直接调用就可以了，也许他封装好的东西里用到了很多HashMap之类的东西，比如框架，很多都用到了。在此基础上在进行性能的优化，你调用起来会很方便。至少那些专家级别的人物在健壮性以及程序的调优上面给予了很好的保证。如果什么都你自己写，你怎么能保证你写出来的算法或者是效率是最好的呢？也许加几行代码就给你搞死了，健壮性难以保证。如果你觉得这么设计很烂。那建议你不要用面向对象的语言吧。还是自己一行一行写过程代码，不然不是自找麻烦吗？

bs那些用了RoR,Groovy,Scala之后把java贬的一无是处的人