其实并不抵触学习新东西和一些“高大上”的概念，但我一直以来最关心的只有一点：我的项目中能不能用到，这东西有什么用，好处是什么，代价是什么？
网上很多都说面向对象的数据库操作方式可以将 Model 层直接解耦，不需要关心它是怎么实现的，而且可以使用 OOP 的方式，如 getXXX() 来获取记录的某个字段值。
其实我一直想做一个游记的网站（类似百度旅游/马蜂窝），目录结构也在 http://.com/q/1010000002890348 提出了，中途也因为看过很多 IoC 的文章很是头疼，发现碍于项目规模很难体现出它的优势，反而是加重负担为了设计而设计。分层已经使得 action 尽量精简，而且 Model 也可以做到不错的复用。
1、实在不知道为什么越来越多使用 ORM 呢？是因为面向对象编程的需要（太笼统了）？还是说我的查询结果对象可以缓存？如果网站访问量大了，是不是把查询结果以对象形式缓存才是最终的解决办法？基于 KV 的 noSQL 是不是也可以替代？那数据库自身的缓存呢？
2、其实解耦真不是最关心的问题（自认为还没达到要解耦的地步，上面的分层带来的复用性已经蛮不错了），ORM 的 builder 看着也是醉了，不如直接 Model 里写 SQL 语句来的痛快，将来换数据库直接重写（不担心这个问题，不差这个时间），感觉性能和复用一直有点点的相悖，那抛开复用性和解耦的需求，如果要用 ORM 是不是就是因为对象缓存的收益？
3、还有之前公司大哥说不要用 join，直接嵌套查询，我说那不是假设文章页 15 篇文章上面有作者信息，我就要跑 15 趟 post 表，中途再跑 15 趟 user 表？他说查询结果可以缓存，不太明白这个缓存是数据库级别的还是 Model 对象级别的？
不一一评论了，谢谢大家的回答!
如果你有10个甚至5个小伙伴一起写SQL，今天这个人JOIN了3个表明天那个人写了子查询，后天另一个人批量update where条件拼错，然后平均每天都有3次因为字段名字写错导致的bug，你就知道ORM的宝贵了
用SQL意味着你无法换库，因为SQL也不是通用的。
用join意味着你的项目只能在一个库，join跨库更复杂。
小项目没必要用orm，就如你说的，不差那个时间，改呗。
但大项目就不一样了，要分库、要换库，今天用mysql明天可能就用了hbase还可能混用。
最近我们也遇到了相同的问题，ORM性能确实比原生sql要低很多，ORM只适合，快速敏捷迭代开发.
Don't fall in the trap of premature optimalization
找到瓶颈制约。才是关键。不要纠结于某一部分的效率。
ORM性能确实会降低一些，这样就要看怎么取舍了 —— 如果说是要迅速把网站搞起来能用，ORM可能会更快，特别是比如有zii之类的代码生成工具
model级别的
推荐一个短小精悍的ActiveRecord库，lloydzhou/activerecord · GitHub， 可以实现类似Yii的relation的效果。文档地址：http://lloydzhou.github.io/activerecord/
class User extends ActiveRecord{
public $table = 'user';
public $primaryKey = 'id';
public $relations = array(
'contacts' => array(self::HAS_MANY, 'Contact', 'user_id')
);
}
class Contact extends ActiveRecord{
}
$user = new User();
// find one user
var_dump($user->notnull('id')->orderby('id desc')->find());
echo "\nContact of User # {$user->id}\n";
// get contacts by using relation:
// 'contacts' => array(self::HAS_MANY, 'Contact', 'user_id'),
var_dump($user->contacts);