※ 引述《StubbornLin (Victor)》之铭言： ※ 引述《wil771126 (雨的印记)》之铭言： (恕删) --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 118.170.171.45 藉这个机会来说说我对 orm 的看法 有错误或是不正确的地方欢迎各位大大指正... Orz 首先我想说的是， Python 有订定 DB 存取的介面： PEP 249 -- Python Database API Specification v2.0 所以介面上的存取其实不太需要像是 Perl / Ruby / Php 还需要导入一层 DBI / PDO 来介接，这也意味着要换资料库其实修改的部分已经可以降到最低， 所以 "我觉得" 在 Python 的世界里，"引入 orm 可以让转换 DB 更容易" 其实不是说服人导入 orm 的理由。再来，仔细想一下 orm 的优势到底在哪里？ 何时适用呢？现在各个 web framework 都内建了各式的 orm，为什麽它们都要用 orm 来做为存取资料库的介面？ 因为 web app "在本质上" 就是一个接收要求 -> 存取资料库的行为，也就是说 web app 一般来说都会 "频繁的存取资料库"。因此何时需要导入 orm，那就是你的专案 本质上就是会非常频繁的和资料库沟通，这时候如果撰写 sql，对程式开发人员来说， 会让程式码变的很肮脏，sql 和程式码混杂在一起。此时引入 orm，可以有效降低 sql 出现在程式码当中的机率，私以为专案有这样的属性，才需要考虑使用 orm。 ---- 但是引入 orm 会有什麽问题呢？ 1. 首先是稳定性的问题，我所说的不是单单指该 orm 套件有没有 bug的稳定性， 还包含了API 的稳定性。基本上引用了一个外部的函式库，我觉得在某种程度上来说， 等於是将程式的稳定性外包给别人。如果该函式库维护者很有经验，很注重向後相容， 也许真的就能符合 DRY 原则，让你可以将时间拿去做别的事... 这点我觉得 Python 社群的函式库都还颇稳定的，不过这点仍然需要纳入考量。 在最好的情况下就是该函式库很稳定，你都可以不用理会这块，那 DRY 原则就是 Don't Repeat Yourself. 反之呢，就是第三方函式库有大大小小的问题，你花在 patch 的时间大於 自己重写的时间，这时我戏称 DRY 原则是 DO Repeat Yourself. 某程式语言的第三方函式库这点我觉得有点严重... (以下抱怨省略三千字) 2. 学习此函式库的时间。复杂的函式库就是要花时间去学习。而且你得花时间精熟。 有人也许认为干麻精熟，能用就好啦。这时就要引经据典 (XD)：人月神话有提到 在团队中最好要有所谓的工具专家。所以如果你的团队中有此 orm 专家，那好，问题 还不大。如果大家都不是很熟，那遇到问题或地雷或 scaling 的问题那就要 烧香拜拜了... 3. 适用度。 orm 到底适不适用你的专案，你得仔细评估。如果未来你的专案会 一直长大，导致DB 存取频繁，这时用 orm 会雪上加霜... 当然现在大部分的 orm 都有可以直接用 raw sql 的方式，不过一但你用了 raw sql... 那用 orm 的意义...? 的确是可以减少 sql 数量，但是此时你的程式码会混杂 orm 逻辑以及 raw sql， 对後面接手的人来说真的比较好维护？这需要思考。 再来，如果你专案未来可能会用到各个资料库的 store procedure、 或是一些特殊的功能，那 orm 也不太适用... ---- 简单来说，我个人是觉得 orm 有其适用性，而且它带来益处的同时，也会带来坏处， 需要评估的地方不少就是...以上是小弟的心得... 有错请鞭小力一点... Q_Q --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 118.166.114.249