Doctrine原生SQL与存储过程替代方案

本篇文章给大家分享《Doctrine原生SQL与存储过程弃用方案》，覆盖了文章的常见基础知识，其实一个语言的全部知识点一篇文章是不可能说完的，但希望通过这些问题，让读者对自己的掌握程度有一定的认识(B 数)，从而弥补自己的不足，更好的掌握它。

本文旨在解决Doctrine ORM中调用原生SQL或存储过程时，`fetchAllAssociative()`和`execute()`等方法被弃用的问题。我们将详细介绍如何利用`ResultSetMapping`结合`createNativeQuery`来安全、高效地执行原生SQL，并以标量结果的形式获取数据，从而实现与弃用方法相同的功能，同时保持代码的现代化和可维护性。

在Doctrine ORM的早期版本中，开发者通常会直接通过Connection对象执行原生SQL或调用存储过程，并使用prepare()、execute()和fetchAllAssociative()等方法来获取结果。然而，随着Doctrine版本的迭代，这些直接操作Statement对象的方法已被标记为弃用，鼓励开发者采用更集成、更健壮的方式来处理原生SQL，尤其是在需要将结果映射到PHP数组时。

弃用方法的挑战

考虑以下使用旧版Doctrine方法调用存储过程的示例：

use Doctrine\ORM\EntityManagerInterface;

class MyRepository
{
    private $entityManager;

    public function __construct(EntityManagerInterface $entityManager)
    {
        this->entityManager = $entityManager;
    }

    public function callStoredProcedureDeprecated(string $param): array
    {
        $sql = 'CALL spWithParams(:param)';
        // prepare() 和 execute() 已弃用，fetchAllAssociative() 也已弃用
        $stmt = $this->entityManager->getConnection()->prepare($sql);
        $stmt->execute([":param" => $param]);
        return $stmt->fetchAllAssociative(); // 返回关联数组
    }
}

这种方式虽然直观，但其直接操作底层数据库连接的Statement对象，与ORM的集成度不高，且随着方法被弃用，维护成本和未来兼容性都面临挑战。

现代解决方案：ResultSetMapping 与 createNativeQuery

Doctrine推荐的现代方法是使用ResultSetMapping（结果集映射）与createNativeQuery。这种方法允许您定义如何将原生SQL查询返回的数据库列映射到PHP数组的键，而无需将结果强制映射到ORM实体。这对于处理存储过程的输出或执行复杂报表查询而不需要完整ORM实体对象时尤其有用。

核心思路是：

1. 定义结果集映射 (ResultSetMapping): 使用addScalarResult()方法指定数据库列名及其对应的PHP数组键名。
2. 创建原生查询 (createNativeQuery): 将SQL语句和定义的ResultSetMapping传递给EntityManager的createNativeQuery()方法。
3. 设置参数: 使用setParameters()安全地绑定查询参数。
4. 获取结果: 调用getArrayResult()方法获取一个包含关联数组的结果集。

下面是使用这种现代方法重写上述存储过程调用的示例：

<?php

namespace App\Repository;

use Doctrine\ORM\EntityManagerInterface;
use Doctrine\ORM\Query\ResultSetMapping;

class MyRepository
{
    private $entityManager;

    public function __construct(EntityManagerInterface $entityManager)
    {
        $this->entityManager = $entityManager;
    }

    /**
     * 调用存储过程并获取标量结果。
     *
     * @param string $param 存储过程参数
     * @return array 返回一个包含关联数组的结果集
     */
    public function callStoredProcedure(string $param): array
    {
        // 1. 定义结果集映射
        // ResultSetMapping 允许我们定义如何将数据库返回的列映射到PHP数组的键。
        // addScalarResult('数据库列名', 'PHP数组键名')
        // 例如，如果存储过程返回一个名为 'my_database_column' 的列，
        // 我们希望在PHP数组中以 'myField' 作为键访问它。
        $rsm = new ResultSetMapping();
        $rsm->addScalarResult('my_database_column', 'myField');
        // 如果存储过程返回多个列，可以多次调用 addScalarResult
        // $rsm->addScalarResult('another_db_column', 'anotherField');

        // 2. 创建原生查询
        // createNativeQuery 方法接受 SQL 语句和 ResultSetMapping 对象。
        // 这将创建一个 Doctrine\ORM\NativeQuery 对象。
        $query = $this->entityManager->createNativeQuery(
            'CALL spWithParams(:param)', // 您的原生SQL或存储过程调用语句
            $rsm
        );

        // 3. 设置查询参数
        // 使用 setParameters 方法安全地绑定参数，防止SQL注入。
        $query->setParameters([
            ':param' => $param // 将 PHP 变量绑定到 SQL 中的 :param 占位符
        ]);

        // 4. 获取结果
        // getArrayResult() 方法执行查询并返回一个包含关联数组的数组。
        // 每个内部数组代表一行结果，键名是您在 addScalarResult 中定义的 PHP 键名。
        $results = $query->getArrayResult();

        /*
         * $results 的预期结构示例:
         * [
         *   ['myField' => 'foo'],
         *   ['myField' => 'bar']
         * ]
         */

        return $results;
    }
}

关键概念解析

1. ResultSetMapping:

   • 这是一个强大的工具，用于在不涉及完整实体映射的情况下，将原生SQL查询的结果映射到PHP数据结构。
   • 通过addScalarResult('database_column_name', 'php_array_key')，您可以精确控制数据库返回的哪些列应该被提取，以及它们在最终PHP数组中应该以什么键名出现。
   • 这对于存储过程特别有用，因为存储过程的输出通常不直接对应于ORM实体。

2. createNativeQuery(string $sql, ResultSetMapping $rsm):

   • 这是EntityManager提供的一个方法，用于创建并执行原生SQL查询。
   • 它接受原生SQL语句和您定义的ResultSetMapping对象。
   • 它返回一个Doctrine\ORM\NativeQuery对象，该对象允许您设置参数并获取结果。

3. setParameters(array $parameters):

   • 用于安全地绑定查询参数。始终使用此方法来传递变量，而不是直接将它们拼接到SQL字符串中，以防止SQL注入攻击。

4. getArrayResult():

   • 执行原生查询并返回一个由关联数组组成的数组。每个内部关联数组代表查询结果中的一行，其键名由ResultSetMapping定义。这与旧版fetchAllAssociative()的行为最为接近。

注意事项与最佳实践

• 安全性: 始终使用参数绑定（setParameters()）来传递变量，避免直接拼接SQL字符串，以防止SQL注入。
• 灵活性: ResultSetMapping提供了极大的灵活性，您无需为每个原生查询都创建完整的ORM实体。这对于报表、统计或调用复杂存储过程的场景非常适用。
• 性能: 对于一些非常复杂的查询或存储过程，直接使用原生SQL可能比DQL（Doctrine Query Language）更高效，因为它绕过了ORM的某些抽象层。然而，过度使用原生SQL可能会牺牲ORM带来的便捷性和可移植性。
• 错误处理: 在实际应用中，您应该添加适当的错误处理机制，例如try-catch块，来捕获数据库操作可能抛出的异常。
• 命名规范: 保持数据库列名和PHP数组键名的清晰对应，即使它们不完全相同，也应易于理解其映射关系。

总结

随着Doctrine版本的演进，直接使用Connection对象的prepare()、execute()和fetchAllAssociative()等方法已被弃用。为了保持代码的现代化和兼容性，推荐采用ResultSetMapping结合createNativeQuery的方式来执行原生SQL和调用存储过程。这种方法不仅提供了与旧方法相似的功能，而且通过明确的映射定义和安全的参数绑定，提升了代码的可读性、可维护性和安全性，是处理Doctrine中原生SQL查询的推荐实践。

以上就是《Doctrine原生SQL与存储过程替代方案》的详细内容，更多关于的资料请关注golang学习网公众号！