Question

尝试分析不同方法的优点或缺点。真的不是在寻找意见，而是寻求或限制这些不同的方法。

Yii声称使用他们的AR简化了DB编程，但我更关心的是将DB与我的代码“过度”混合。我显然知道它们一起工作，但映射有点令人担忧。我希望在数据库中存在尽可能多的控件和约束，并且想知道如果远离纯SQL可能会限制性能。

Answer 1

ActiveRecord适用于任何具有非常简单的ORM的系统，其中Model == Table，具有1对1的关系。换句话说，如果您的所有数据对象都适合单个表（可能还有一些与之相关的额外表），ActiveRecord就适合您。而且你通常可以设计你的软件，所以情况就是这样！

但你是对的，它确实“网格化”数据库实现和代码。假设表示Model == Table，这意味着数据库实现并不与您的代码分开。如果复杂的模型存储在多个表中，ActiveRecord会分解一些。但那是rather involved argument我不会接受的。其他模式（如Data Mapper）为您提供了更大的灵活性，但最初需要更多工作才能进行编码。

ActiveRecords设置它忘了它。简单快捷。没有繁琐的getter和setter编码，只需从表中构建好的PHP对象。我最近用Yii构建了一个非常大的应用程序，我喜欢ActiveRecord的速度和简单性。我现在正在使用Zend中的应用程序，即使我可以看到他们的方式如何为您提供更多控制，但我会错过AR的简易性。 ;）

Answer 2

Yii ActiveRecord肯定简化了对数据库的编程，当然任何体面的ActiveRecord实现都可以。

映射到db

关于数据库和模型之间的映射，您的代码不会“接管”您的数据库。您强制唯一保持最新状态的是：

/**
 * @return string the associated database table name
 */
public function tableName()
{
    return 'my_table';
}

看到表名不会经常改变，这不是一个实际问题。

ActiveRecord模型的其他部分应与您的架构保持同步：

描述模型类属性的phpdoc注释
实现各种功能的其他公共函数，例如验证规则[public function rules()]，外部模型关系[public function relations()]，属性标签[public function attributeLabels()]等。

但是，您仍然可以使用模型和数据库本身，即使这些不反映您当前的数据库模式 - 只是相应的功能位将不再有效。

这些数据不会强制执行您的数据库约束，它们只是通过允许您以更直观的方式访问功能来帮助您。实际约束仍然实现在数据库中。

效果

Yii实现了一个query builder，您可以使用它从流畅的表达式生成SQL（您的模型在直接查询时使用相同的机制）。构建器从fluent表达式生成SQL，结果不会比直接执行等效SQL时慢。

当然，使用查询构建器本身会有一些开销，但这是几乎所有现代编程语言都选择做出的权衡（LINQ将是这里最大的例子），因为它是完全值得的。 / p>

在任何情况下，您都可以使用CDbCommand自行编写SQL查询。我没有看到这样做的理由，但如果你需要它，那么选项总是在那里。因此，无论你需要做什么，都不可能因为ActiveRecord的不足而陷入困境。

纯SQL，Yii活动记录或混合

2 个答案:

映射到db

效果