PHP 数据库 ORM 实现的必要性

LemonLone
  • 237

其实并不抵触学习新东西和一些“高大上”的概念,但我一直以来最关心的只有一点:我的项目中能不能用到,这东西有什么用,好处是什么,代价是什么?

网上很多都说面向对象的数据库操作方式可以将 Model 层直接解耦,不需要关心它是怎么实现的,而且可以使用 OOP 的方式,如 getXXX() 来获取记录的某个字段值。

其实我一直想做一个游记的网站(类似百度旅游/马蜂窝),目录结构也在 http://segmentfault.com/q/1010000002890348 提出了,中途也因为看过很多 IoC 的文章很是头疼,发现碍于项目规模很难体现出它的优势,反而是加重负担为了设计而设计。分层已经使得 action 尽量精简,而且 Model 也可以做到不错的复用。

1、实在不知道为什么越来越多使用 ORM 呢?是因为面向对象编程的需要(太笼统了)?还是说我的查询结果对象可以缓存?如果网站访问量大了,是不是把查询结果以对象形式缓存才是最终的解决办法?基于 KV 的 noSQL 是不是也可以替代?那数据库自身的缓存呢?

2、其实解耦真不是最关心的问题(自认为还没达到要解耦的地步,上面的分层带来的复用性已经蛮不错了),ORM 的 builder 看着也是醉了,不如直接 Model 里写 SQL 语句来的痛快,将来换数据库直接重写(不担心这个问题,不差这个时间),感觉性能和复用一直有点点的相悖,那抛开复用性和解耦的需求,如果要用 ORM 是不是就是因为对象缓存的收益?

3、还有之前公司大哥说不要用 join,直接嵌套查询,我说那不是假设文章页 15 篇文章上面有作者信息,我就要跑 15 趟 post 表,中途再跑 15 趟 user 表?他说查询结果可以缓存,不太明白这个缓存是数据库级别的还是 Model 对象级别的?


不一一评论了,谢谢大家的回答!

回复
阅读 6.8k
7 个回答
✓ 已被采纳

如果你有10个甚至5个小伙伴一起写SQL,今天这个人JOIN了3个表明天那个人写了子查询,后天另一个人批量update where条件拼错,然后平均每天都有3次因为字段名字写错导致的bug,你就知道ORM的宝贵了

Don't fall in the trap of premature optimalization
找到瓶颈制约。才是关键。不要纠结于某一部分的效率。

用SQL意味着你无法换库,因为SQL也不是通用的。
用join意味着你的项目只能在一个库,join跨库更复杂。
小项目没必要用orm,就如你说的,不差那个时间,改呗。

但大项目就不一样了,要分库、要换库,今天用mysql明天可能就用了hbase还可能混用。

最近我们也遇到了相同的问题,ORM性能确实比原生sql要低很多,ORM只适合,快速敏捷迭代开发.

ORM性能确实会降低一些,这样就要看怎么取舍了 —— 如果说是要迅速把网站搞起来能用,ORM可能会更快,特别是比如有zii之类的代码生成工具

推荐一个短小精悍的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);
撰写回答
你尚未登录,登录后可以
  • 和开发者交流问题的细节
  • 关注并接收问题和回答的更新提醒
  • 参与内容的编辑和改进,让解决方法与时俱进
宣传栏