这些年 Web 领域新技术/框架/库层出不穷，但部分讨论帖有一种脱离了业务的感觉，这是我理解出现了偏差么？

因为你没搞过 Java ，搞过 Java 的人都知道， MVC ORM DI AOP XXX 这些都是 Java 业界玩剩下的东西，

PHP5 才开始完全支持 OO

Java 自从 1998 年发布 JavaEE 规范开始，模块化 分层解耦 就根植于 Java 的 web 开发当中，而 Java 一开始就是一门
非常好的 OO 语言，而且 JVM 运行时支持反射 以及 代理，为框架 DI AOP 提供了支持

PHP5 才开始完全支持 OO

从 SpringMVC 以及 xBatis 流行开始， Java 就从 JavaEE 重型框架中摆脱出来了，开始走轻量化之路 加上 Java 社区原本大量的开源后端模块

然而 PHP5 才开始完全支持 OO

@q397064399 Java 自从 1998 年发布 JavaEE 规范开始，模块化 分层解耦 就根植于 Java 的 web 开发当中

是 JavaEE

@q397064399

然而我的疑惑并不在 OO ，而是这类文章经常脱离业务谈论各种框架
就像 ORM ，并不是所有场景都适合用 ORM ，但这个帖子直接认为 2016 年没人写 SQL

@q397064399 然而 php5 也是 2005 年发布的，也已经 10+年了，别说的好像刚发布一样。另外国内的 php 环境至少落后国际上一个时代，看看 composer 在国内和国际的普及程度就知道了。
顺便说一句，那个帖子里提到的很多东西，我觉得更多的是借鉴 ruby （更准确的说， ror ）而非 java 。


@mhycy 绝大多数业务场景还不需要考虑运行效率，而 ORM 在那些场景下能够大幅提升开发效率。

@jhdxr
然而我也没提到运行效率。
如果是面对复杂的业务系统的时候（各种 ERP ）， SQL 能比 ORM 有更高的灵活性。

@mhycy 我觉得需要些复杂 sql 的时候，一般来说首先就不会选择 MySQL 了。。。然后跟着也不大会考虑 PHP 了。。。（国内 php+pgsql 的组合几乎没见过，日本那倒不少）

@mhycy 但是 SQL 有更高的维护成本，新人更难加入开发的队伍， Java 的出现就是为了让萌新都能成为干活的队友出现的。绝大多数的所谓灵活性都是为了一时自己开发爽。一个系统从业务逻辑以及架构设计上调整去适配 ORM 我觉得才是正路，因为 ORM 的学习成本比 SQL 低，那么就代表要成为你队友的门槛低，工作能通过堆实习生解决的问题都不是问题。
当然你的队友都很强，你们都能写出壮健性能高简洁明了的代码，那么当我没说。

@mhycy 你可以考虑轻量级 ORM 框架 xBatis 就是

@neoblackcap 有点时候我有点怀疑 MyBatis ， SQL 几乎全部手写，当然也有自动生成工具，全手写的话，还有意义么？

@jhdxr 看来你们都是面对场景并不复杂的互联网应用啊，对于企业内部的一些表单型的数据，很多时候除了 SQL 以外没别的建库形式可以替代的。

@neoblackcap 请指教 SQL 更高的维护成本从何而来。事实上在使用过程中 SQL 会抽象成一个个 API 再进行调用的。
（某些数据多表关联写入的情况下必定要抽象出一个 API 进行处理）
写 SQL 可不意味着是业务内直接写 SQL 语句，也不意味着是拼接 SQL 语句，查询生成还是要有的。

@mhycy 我说的 SQL 维护成本高就是指新人需要懂 SQL ，我更加指的是裸 SQL 。
你说的查询生成在我看来本质上就是 ORM ，你这样用没有问题，只不过你有没有试过 benchmark ？性能有没有提高？文档跟其他的 ORM 框架比起来怎么样？总不可能每个接触这套东西的人都来人肉问你吧？就算你愿意回答，你真有这么多时间吗？这些在我看来都是维护成本，至于为什么说裸 SQL 维护成本更大呢？原因是新人不用去了解各个数据库的 SQL 实现，他也不用去思考你这套东西跟已有部件的组合。
同时不要神化 SQL ， SQL 能解决很多问题，但是用程序一样能解决，比如外键什么的都能自己进行检查来约束，数据库完全可以当成一个存储引擎外加+SQL 接口的组件来使用
我并不是排斥 SQL ，任何的事情都是要看环境的，你们适合的不一定适合其他人，可能你们本身团队的人员就比较强，我讨论的只是普遍情况下 ORM 可以解决大多数问题，而且很多问题可以通过软件设计来配合使用纯 ORM 的方式进行开发。

ORM 不用刻意使用啊，如果你用了 Yii 框架，就自然而然用上 ORM 了。