在Symfony2中的动作之间发送PDO的最佳方法是什么?

时间:2015-01-29 19:42:51

标签: php symfony pdo twig

在控制器的操作中,我从数据库加载PDO对象并将其发送到树枝模板以呈现数据网格:

/**
 * @Route("/action1", name="action1")
 * @Template()
 */
public function action1Action(Request $request)
{
    $mydata = $this->daoClass->getData();
    return array(
        'mydata' => $mydata
    );
}

使用Doctrine加载$ myData,它返回一个带有(小)结果数组(PDO Object)的PDO对象。我这样渲染:

<table>
    {% for data in mydata %}
        <tr>
            <td>{{ data.foo }}</td>
            <td>{{ data.bar }}</td>
        </tr>
    {% endfor %}
</table>

所以在twig模板中,在包含数据的表下面,我得到了这个表单,它将数据发送到下一个动作:

<form action="{{ path('action2') }}" method="post">
    <!-- some javascript populated fields -->
    <input type="hidden" id="field1" name="field1">
   ...
</form>

如何让它也发送渲染网格(mydata对象)的PDO对象?

我尝试在第一个操作中将其插入到会话中,以便我可以在下一个操作中检索它但收到消息:“您无法序列化或反序列化PDO实例”

有没有更好的方法呢?

我在这个模块中没有使用symfony表单,因为这是一个过于复杂的屏幕,有很多验证和计算字段,使用表单要复杂得多。

2 个答案:

答案 0 :(得分:3)

  

有没有更好的方法呢?

是的,使用symfony表格。

  

我没有在此模块中使用symfony表单,因为这是一个过于复杂的屏幕,包含大量验证和计算字段,使用表单会更加复杂。

尽可能复杂。使用symfony表单进行映射,视图和symfony验证是非常强大的工具。编写自己的表单,映射和验证是不必要的。

  

在Symfony2中的操作之间发送PDO的最佳方式是什么?

答案绝对不是将Doctrine实体保存到会话或Memcache中,原因是:

//从评论中复制

考虑范围。 PHP启动,做某事,终止。您只能保存范围不受限制的数据。例如,一个简单的字符串没有范围。您只能存储此类数据,但不能存储智能PDO对象。例如,doctrine实体实际上只是一些带有getter和setter的属性,但是doctrine正在为它们实现代理模式做一些魔术。因此,他们扩展了一些访问逻辑,说明如果调用任何setter或getter,首先从数据库加载对象。如果你要存储它们并重新加载它们,它们就会有对象的死引用。

答案 1 :(得分:0)

首先,出于性能原因,不要做你想做的事情。

您尝试做的事情称为过早优化,它是not good

这里有人试图做very similar thing to what you're doing and they are having a hard time

但是,如果您想暂时将信息存储到其他页面,请使用Symfony Sessions

如果你跳过我说的话,让我再说一遍:

警告:不建议将此代码用于PDO结果

use Symfony\Component\HttpFoundation\Session\Session;

$session = new Session();
$session->start();

// set and get session attributes
//Controller ExampleMethodAction1()
$Person = new Person();
$Person->setName('John');
$session->set('PersonObject', $Person);


//Then in another controller method
//Controller ExampleMethodAction2()
$Person = $session->get('PersonObject');
$Person->getName(); //returns John

关于性能的另一个问题是,购买更多硬件要比雇用新开发人员来优化代码更便宜。