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