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

你不会产生"早晚要为表面上的简单付出代价"这样的忧虑么?

这种忧虑本质上来源"没有免费的午餐!!"

所以不在于方法的简单与否,因为本身软件领域就没有简单的事

使用方式简单通常会带来两种局限:

1 针对问题的作用域越小

2 支撑背景越广

良好的设计永远大于实现，你们甚至不明白框架存在的意义

没错！一切都是有前提的，前提的前提是上帝是存在的，人活着是有意义的。

PHP 不能做到Web代码和后台都同一种语言，同一种思维。复杂项目如守护进程还需要 C/Java 程序员来写。

Java 能解决这个问题

 

现在的 PHP 程序证明使用其实所谓 Web 层面的 MVC 分离可以做得很简单。

不幸的是 PHP 框架却陷入 Java 的误区。

 

当初没有 ORM 出现的时候我们是怎么用 Java 做 web 开发的？

当初的 JSP/ASP 把显示输出和 获取数据都混合在一起

我刚写 PHP 的时候也是 把读取数据库数据和打印这些数据混合在一起。后来看了开源的代码才赞叹用数组保存数据库数据的优美。

但是 Java 开发却跳过了这个。所有变化不一定是进化。

 

每个应用都是独特。的对程序员来说。改 SQL 比改 HQL 要更方便。如果认为 SQL 要经常改动，那可以放到配置文件里，实际上，很多应用都只需要固定的 数据库结构，固定的 SQL 代码。

用 POJO(哦，是这样拼写的么) 和 HashMap 关联数组没什么不同。 单纯的 setter/getter 和 hashmap 没什么不同

 

你说的不对，比如，我打算从数据库里取出一个 Person 对象， Person 的类如下:

public class Person{
   public int id;
   public String name;
}

如果是 HashMap ， 你虽然取出来了，但是在使用的时候会很不方便，比如，取name或者id ，你都要转型。

其实，无论怎样我们大多数人都是在应用技术，至于选择哪种技术以及如何使用，还是需要市场为导向。以money为基础。

技术和框架，解决方案都是为了在特定环境下解决特定问题的。


~==========

框架不等于设计，我赞同你的前半句话，但不敢苟同框架就是对所开发项目的良好设计，使开发简单化应该是我们的一种选择，简单化的同时提高的是开发效率，如果没有这种趋势，那么动态语言的兴盛就不会成为可能。
在开发中不选择框架基本是不可能的，但是，我们要选择什么样的框架？我们要基于什么基础来选择框架？
我认为第一，看是否符合项目目标，第二，是否能让开发变得简单，第三，所选框架的运行效率是否能够接受。

不同的时代，不同的领域，软件开发会面临不同的问题，然而，在特定的时代和领域里，人们往往遇到类似的问题，所以才会有那个时代和领域里特定的技术或框架。一旦有成熟的技术和框架解决了旧的问题，人们很快又会发现新的问题，于是又催生新的技术和框架。于是这个世界才会在否定之否定中前进。但是，你不能否定过去存在的意义，即使在现代看来那是不成功或则不正确的，因为没有过去，就没有现在。

楼主的假设其实就是我说指的特定时代和领域里的特定的共通的问题。

这两个目标是一致的吧

这两个目标是互相矛盾的吧

所以是得不出这个结论的吧

简单有简单的道理，复杂有复杂的原因。人月神话的作者就认为没有银弹。还有所谓的框架这是解决问题的方法工具，没有上升到理论的高度，所以被抛弃只是他们不再适手了，没必要为此感怀，除非计算机网络和操作系统这些基础理论变了，至少面向对象方法论变了才值得我们去感慨