Eloquent ORM 号称 Laravel 中最慢的部分,抛开性能不讲, 大家对 ORM 的态度是怎么样的?公司内一直在用吗?
我个人一直很不喜欢 ORM ,原因有以下四点:
如果是 Java 的话,从 SQL 的结果转对象需要大量代码,所以用用 还行, PHP 我始终感觉没有必要。
1
wesley 2016-06-28 10:24:27 +08:00 3
你列的 4 条只有第 4 条存在, 其他的都不正确
|
2
pony279 2016-06-28 10:26:29 +08:00
代码漂亮
除此以外没什么卵用 |
3
jarlyyn 2016-06-28 10:31:10 +08:00
用。
不用难道直接写 sql 么。 个人觉得,性能可以靠缓存和硬件来提升,而且对于大部分项目来说性能并不是最重要的点。 可维护性大部分情况下更重要点。 |
4
kideny 2016-06-28 10:33:51 +08:00 1
大冬天穿裙子,美丽冻人。
是这个意思嘛? |
5
tabris17 2016-06-28 10:36:04 +08:00
新手写 sql 太容易出事了,所以还是 ORM 让人安心些,慢就慢了,不差这几毫秒
|
6
icybee 2016-06-28 10:39:24 +08:00
php 与否,相对于 sql 我更喜欢 ORM ,首先是我觉得 ORM 有助于代码的维护和重构,有利于直观展示数据库结构,甚至直接利用框架迁移数据库( laravel,django ),其次是大部分 ORM 框架都很好的解决了注入和 charset 的问题,至于 LZ 说的几我认为是存在的,但是这些问题并不能掩盖 ORM 的闪光点
|
7
hpan 2016-06-28 10:39:40 +08:00
hibernate 搞个 hql 出来真是有点莫名其妙
|
8
pubby 2016-06-28 10:43:06 +08:00
用! 99%的项目都碰不到"性能"问题
一直用 Propel ORM |
9
murmur 2016-06-28 10:44:34 +08:00
缓存做好 索引建好 表设计好 orm 的性能可以忽略不计 如果真有性能问题先找自己问题
|
10
fromsep 2016-06-28 10:46:20 +08:00
我个人感觉没有直接写 sql 来的爽
|
11
chmlai 2016-06-28 10:48:00 +08:00
什么年代了, 还有人纠结用不用 ORM?
|
12
Felldeadbird 2016-06-28 10:49:52 +08:00
基于这点就不会纠结:
简单得直接 ORM 。 复杂的必须原生 SQL 。 |
13
wjfz 2016-06-28 10:54:40 +08:00 2
几年前争论的点是要不要用框架。
|
14
yao978318542 2016-06-28 11:19:22 +08:00
我的天 我只用过 TP 怎么办?好慌!会不会暴露!
|
15
mahone3297 2016-06-28 11:21:51 +08:00
@wesley +1
|
16
b821025551b 2016-06-28 11:25:59 +08:00
@yao978318542 TP 里的 M 方法不就是 ORM 么。。。
|
17
zaishanfeng 2016-06-28 11:27:58 +08:00 1
现在硬件这么便宜还谈性能? 如果性能出问题,请检查你的架构。 php 端很少出现性能问题
|
18
lightening 2016-06-28 11:37:13 +08:00 via iPhone
不用 php, 但是用 ORM
1. 灵活。可以方便组合各种参数而不用自己拼字符串 2. 移植方便。比如从 MySQL 换到 pg 基本不用花特别的精力。如果有 migration ,方便解决生产环境数据库部署。 3. 代码清晰易读,易于维护 4. 安全,不用自己担心 said 注入 |
19
wclssdn 2016-06-28 11:40:24 +08:00 1
1. 我觉得 orm 相当灵活, ModelA::with(modelB) 直接就把 modelB 关联数据取出来了,不叫灵活么?
2. 你写 sql 的时候,是针对 mysql 的么?如果移植到其他 db ,还能用否? 3. 不会就去学,错用?说明你不会啊。。。就像普通 sql ,你会的语法是 100%么? 4.开启你的 mysql general_log ,然后看下 orm 给出的 sql 结果,跟你自己写的,哪个好?性能问题,也是 php 层面上多执行了一些方法而已。在 sql 上,比你拼的都好(用第一个问题的例子试试看就知道了。。。 工欲善其事必先利其器,提高生产力的东西,为何不用呢??? 人区别于动物,就是因为人善于用工具啊。。。否则就真的是程序“猿”了。。。。 |
20
stormpeach 2016-06-28 11:48:22 +08:00
方便,不用自己担心注入问题,大大增加了可维护性。
|
21
500miles 2016-06-28 12:03:37 +08:00
除了第四点 性能问题, 前面三点可都是 ORM 的好处啊...
php 构建 sql, 进行 record 映射. 这部分消耗都可以忽略了.. 主要的性能影响, 还是在 sql 执行部分 1. 你手写 sql 看到 "select * ...." 肯定不能忍吧? 但是 对于好多人来说, 用 ORM 时 看不到 这个 "*", 也就眼不见为净, 为了简洁, 为了优雅, 为了写的快, 也就不管了 2. 关联关系, 这个问题很难解决 你手写 sql 一句 sql 搞掂的事, 交给 ORM 最少两条 . . . . . . 但是 这些相对于 ORM 带来的好处来说, 也可以忽略了... 2333333 安心的用吧 |
22
jy01264313 2016-06-28 12:10:39 +08:00
帖一条你写的 SQL 出来看看
|
24
zhengkai 2016-06-28 12:37:59 +08:00
太大和太小的项目都不需要 ORM
|
25
Jakesoft 2016-06-28 12:39:46 +08:00
@b821025551b 那个 M 方法还真不是 ORM 。。。
|
26
skyworker 2016-06-28 12:49:31 +08:00
不是很灵活。
那是你不会用. Eloquent 用好 DB::raw()的话不知道有多灵活. |
27
broadliyn 2016-06-28 13:29:31 +08:00
你所谓那点性能问题还真不是啥问题。到阿里粑粑、 twitter 、 facebook 这种量级,所谓的性能都已经钻到语言层面了。
|
28
hwsdien 2016-06-28 13:32:05 +08:00
写多了 SQL ,总有一天你自己会抽象一个 ORM 出来...
|
29
qhxin 2016-06-28 13:35:28 +08:00
很好用的
|
30
ilskenyf 2016-06-28 13:46:06 +08:00
容易维护 容易写 api
https://github.com/libern/someline-starter |
31
msg7086 2016-06-28 13:48:25 +08:00
现在不写 PHP ,但是用 ORM 。
这么说吧,你手写 SQL 的时候自带了缓存机制吗? 多级关联查询的时候有缓存机制吗? 写入数据的时候带了参数绑定和类型检查吗? 更新的时候有脏数据标记吗? 啥都没有你玩啥数据库。光一个缓存机制就可以甩你手写了。 更不提移植性什么的。 |
32
darluc 2016-06-28 14:09:40 +08:00
我觉得这个问题得从工程和编程思维的方面来理解:
1. ORM 更符合面向对象思维; 2. ORM 的抽象,使得项目更加容易维护; |
33
yannxia 2016-06-28 15:04:47 +08:00
如果不需要快速开发,另外长时间稳定数据库选择就可以不用 ORM
|
34
ilskenyf 2016-06-28 15:06:44 +08:00
推荐楼主用 phalcon
|
35
S4m 2016-06-28 15:22:45 +08:00
就一个很单纯的问题,用 ORM 几乎就不会产生 SQL 注入了。
|
36
aksoft 2016-06-28 15:33:03 +08:00
我觉得楼主不适合用框架,直接 echo sql 更好更快
|
37
jswh 2016-06-28 15:41:26 +08:00
ORM 是对数据对象的封装,用还是不用还是看你怎么设计整个框架。如果有好的封装形式不用也没问题吧。
|
38
hantsy 2016-06-28 15:53:58 +08:00
2. 移植不方便。。。
我是服了你。。。 ORM 最大的好处就是各数据库之间移植性。。。 用过 Doctrine 。。。不要太好用啊。从 Java 过来的,用 Doctrine 零曲线。 |
40
changwei 2016-06-28 15:59:53 +08:00
我也不喜欢用 ORM ,所以我都是直接写原生 SQL ,我觉得原生的比较直观,而且涉及到很复杂的比如说查询带有子查询, N 张表连接。
当然一些很简单的,比如说单表查询,单 where 条件,直接用 orm 代码比较少,我喜欢。 性能倒不是问题,现在 CPU 这么快,性能瓶颈已经不再代码层了,都在 IO 方面 |
41
sunmonster 2016-06-28 16:08:36 +08:00
偏向于只用 QueryBuilder
|