考虑以下场景
我们有一个简单的数据库，涉及两个实体： user 和 category .
对于我们的假设，假设一个user只能具有一种类型的category，而category可以与 n users相关联。
现在，考虑一个网页，其中user - 比如ROLE_ADMINISTRATOR - 可以编辑用户表并将它们关联到不同的category。
据我所知（总的来说，我仍然是symfony的新手），如果我同时使用Doctrine和symfony2，比方说，注释方法，我将有两个实体（php类）。
嵌入式表单
我将创建一个表单来显示user，并且为了显示 - 当然，并坚持下去！- 也是他category我"选择"遵循"嵌入式形式"策略。
话虽如此，实体已经创建，我将不得不为category创建一个表单（假设在formBuilder中我只会添加id category的属性）。
之后，我必须将以前的表单添加到UserType类formBuilder，并且通过"某种魔术"，表单将（经过适当的操作）呈现为魔术，同样神奇的是，当我将其发布（和绑定，等等）时，所有信息都将保留在数据库中
数据转换器
又名将表单的输入转换为对象，反之亦然。
这样，我就必须定义一个 - 比方说 - CategorySelectorType到他的生成器中，将添加一个类（服务？）来执行这些转换。
现在我们定义数据转换器本身，它将实现DataTransofmerInterface（使用他的方法等等......
下一步是将该实体注册到服务中，并将使用此服务的表单添加到UserType。
所以我不明白这两种计量学之间的任何"强"区别，而是服务的"可重用性"。有人可以给我一个不同的观点，并向我解释差异，如果有的话？
数据转换器不会取代嵌入式表单，而是增强表单并很好地包装数据转换。
关于数据转换器的食谱页面上的第一句话很好地总结了它：
您经常会发现需要转换用户在 形成其他内容以在程序中使用。
在上面的示例中，您可以添加一个类别下拉列表，以便管理员可以为给定用户选择一个类别。这将使用嵌入式表单完成。由于类别字段是现有类别的 ID，因此无需转换数据。
出于某种原因，您现在希望管理员能够输入类别的自由文本。现在，您需要将文本转换为相关对象。也许您希望他能够使用此文本字段添加新类别或选择当前类别。两者都可以通过使用数据转换器来实现，该转换器获取文本并搜索类别。根据您的需要，可以创建和返回非现有类别。
另一个用例是当用户输入的数据在存储之前需要以某种方式修改时。假设用户输入了街道、门牌号和城市，但您想改为存储坐标。
在这两种情况下，是否将表单嵌入到另一个表单中都没有关系！
你能在你的控制器中做到这一点吗？答案是肯定的。在控制器中执行此类操作是个好主意吗？可能不是，因为您很难进行测试（在转换器中执行此操作可以让您很好地单元测试转换）或重用它。
更新
当然，可以将转换代码放在其他地方。用户对象本身不是一个好地方，因为模型不应该知道执行转换所需的实体管理器。用户类型是可能的，但这意味着它与实体管理器相关联。
这一切都加起来是一个非常强大的关注点分离概念，它指出一个类应该只做一件事来使其可维护、可依赖、可测试等等。如果您遵循此概念，那么应该清楚数据转换本身就是一回事，应该受到威胁。如果您不在乎，则可能不需要转换功能。