0

前段时间完成了一个应用程序，我已经开始优化了，但是还有一些事情还没有优化，例如保存过程，很多人会说这太简单了，你不需要优化它.

现在我的应用程序有一些特定的要求，都通过 JSON API 公开。这导致我选择了 JMSSerializer 之类的工具来进行对象的作业序列化。问题是我有几个密切相关的实体，因为序列化递归地访问每个属性，这可能会成为一个大问题，尤其是当您开始取消记录时。50K、100K 或 1M。JMS 序列化变得繁重，应用程序响应变得缓慢。

JMS 现在提供排除策略，我目前正在使用组，但这又回到了地狱，我的问题是：一张桌子有两个实体（轻和重）是不是很糟糕？这可能吗？

我的问题集中在通过表单编辑的实体的某些属性上，但大多数字段不是（主要是与其他实体的关系）

可能这一切只是我在精神疲劳的时刻发生的愚蠢，但如果我想阅读一些关于如何避免这种情况而不必创建复杂的排除规则的意见或建议

希望这样的解决方案集中并设计为与 symfony 和 Doctrine 的组件一起使用

4

2 回答 2

0

我们在序列化组失控时遇到了同样的问题，并考虑了几个选项。我们最终创建了一个命名方案并使用数组来尝试控制序列化组的扩散。

在我们的实体中，我们以关系命名序列化组。所有基本实体字段都只是以实体命名（可能是缩写）。

* @Groups({'EntityA_EntityB'})

然后我们根据使用情况在实体中创建序列化组数组

static $lightView = array('EntityA','EntityA_EntityB', 'EntityA_EntityC');

然后在控制器中我们可以轻松获取组

private $viewGroup = array_merege(EntityA::$lightView, EntityC::$lightView);

它实际上只是标准序列化组的一个薄层，但这意味着我们不必创建这么多组，并且它们都在一个地方进行管理（无需滚动添加到注释的实体）。我们所有的实体都被序列化为 json 并发送到客户端以在 knockout.js 中呈现，所以我觉得你在尝试管理不断增长的序列化组列表时很痛苦。

于 2013-10-09T10:22:46.430 回答
0

嗯，有（部分）你的答案：

% app/console doctrine:schema:update --dump-sql
[Doctrine\DBAL\Schema\SchemaException]
The table with name 'foo.foo' already exists.

在某些情况下它可能会起作用（如果不使用任何与 Schema/SchemaTool 相关的东西的话），但是在许多其他情况下它会给你带来麻烦。

更传统的方法是将实体拆分为两个单独的实体，一个仅具有“轻”部分，另一个仅具有附加的“重”部分，并通过一对一的关系将两者连接起来。然后使用“Light”实体上的序列化程序组来控制“Heavy”部分是否会被序列化。

于 2013-10-08T20:14:08.010 回答