我开始掌握 CodeIgniter 并发现它支持 Active Record 模式。
我喜欢它为您生成 SQL 代码的事实，因此基本上您可以检索、更新和将数据插入到数据库中，而无需将您的应用程序绑定到特定的数据库引擎。
它使简单的查询变得非常简单，但我担心的是，如果不是不可能的话（例如，如果需要引擎特定的功能），它会使复杂的查询变得更加复杂。
我的问题
您对此模式有何看法，尤其是在 CodeIgniters 实现方面？
将数据库包装在另一层是否存在速度问题？
在尝试构建非常复杂的查询时（逻辑）是否会变得混乱？
利大于弊吗？
【问题讨论】：
标签： php database design-patterns activerecord codeigniter
您对这种模式有何看法（原文如此），尤其是关于 CodeIgniters 的实现？
关于 CI 的实现不能说太多。一般来说，除了最简单的应用程序之外，我会避免使用 AR。如果表与我的业务对象不匹配 1:1，我不使用 AR，因为它会使应用程序建模变得困难。我也不喜欢将持久层耦合到我的业务对象的想法。这违反了关注点分离。为什么产品应该知道如何自救？延伸阅读：http://kore-nordmann.de/blog/why_active_record_sucks.html
编辑 在@kemp 发表评论后，我查看了 CI 用户指南，了解他们如何实现 AR：
正如您在PoEAA 中看到的那样，AR 是在数据库表或视图中包装一行、封装数据库访问并在该数据上添加域逻辑的对象。 这不是虽然 CI 做了什么。它只是提供了一个 API 来构建查询。我知道有一个扩展 AR 的 Model 类，可以用来构建业务对象，但那更像是Row Data Gateway。查看 PHPActiveRecord 了解替代实现。
将数据库包装在另一层是否存在速度问题？
每当您将某些内容抽象或包装到其他内容中时，您可以确定这会比原始操作带来性能影响。问题是，您的申请是否可以接受。找出答案的唯一方法是通过基准测试。延伸阅读：https://stackoverflow.com/search?q=orm+slow
编辑 对于 CI 的简单查询构建 API，我认为性能影响可以忽略不计。从逻辑上讲，组装查询将比仅使用将原始 SQL 字符串传递给 db 适配器花费更多时间，但这应该只是微秒。据我在用户指南中看到的，您还可以缓存查询字符串。但如有疑问，请进行基准测试。
在尝试构建非常复杂的查询时（逻辑）是否会变得混乱？
取决于您的查询。我见过相当混乱的 SQL 查询。当通过 OO 接口表达时，它们并没有变得更漂亮。根据 API，您可能会发现无法通过它表达的查询。但话又说回来，这取决于您的查询。
利大于弊吗？
只有你可以决定。如果它使您作为程序员的生活变得轻松，那当然可以。如果它符合您的编程需求，是的。 Ruby on Rails 大量构建在该 (AR) 概念之上，所以它不会那么糟糕（尽管我们也可以就此争论 :)）
【讨论】：
好的，首先 99% 的查询都是简单的选择/插入/更新/删除。对于这个活跃的记录是伟大的。它提供了可以轻松更改的简单语法。对于更复杂的查询，您应该只使用查询方法。这就是它的用途。
其次，它为这些查询提供了转义和安全性。面对现实，您的应用程序可能会有数百甚至数千个查询发生的地方。你一定会搞砸并忘记适当地逃避其中的一些。活动记录不会忘记。
第三，根据我的经验，性能并没有受到显着影响。当然是，但每个查询可能大约 0.00001。我认为这对于它为您所做的附加安全性和健全性检查是完全可以接受的。
最后，我认为很明显，我相信优势远大于劣势。拥有即使是最初级的开发人员也能理解且不会搞砸的安全查询是一件很棒的事情。
【讨论】：