首先，我不知道我的头衔是否清晰，事实上他们不是我的话。
我的工作非常简单＆＃34;我公司的项目：用几个屏幕建立一个结账：优惠，登录，注册，忘记密码，用户信息，确认。我们有一个口。
我们是这个项目的3名开发人员。 2名大三学生包括我和1名首席开发人员。
首席开发人员表示，他希望将业务逻辑与实体分开。如果我们不这样做，我们最终会得到一个有着未来需求的太大的实体，以及带有它的学说经理＆＃34;。但是User实体实现了Serializable接口，我们只引用绕过任何Doctrine引用的用户属性。他提到DTO很多时间，我搜索并且不理解某个特定的东西。
因此，他不是以最经典的方式（学说映射，验证器断言）创建用户实体，而是创建两个类。
A＆＃34;模型＆＃34;表示用户使用验证器注释输入的用户类，然后将数据传递给服务以调用另一个作为实体的User类上的某些setter，然后将其保留。
请注意＆＃34;型号＆＃34;用户类不在经典的Entity命名空间中，是的，它对于Symfony和Doctrine ORM的经典行为去选择注释/映射信息和其他东西很重要。）
他让我写一些关于用户注册的单元测试和功能测试。在几次断言之后，我尝试检索验证器元数据以检查它们是否被尊重。更确切地说，验证者错误消息。
但是对UniqueEntity注释的评估不起作用，并且表明无法找到对象的对象管理器（请记住，他将断言放在＆＃34; Model＆＃34;用户中而不是实体1），但表示＆＃34; entityClass（https://symfony.com/doc/current/reference/constraints/UniqueEntity.html#entityclass）＆＃34;指向实体的值
我试图陈述事实而不包括我的判断和强硬。
我认为我仍然可以使用PropertyInfo组件来访问注释，我明天会尝试。
但你怎么看待这一切？您如何看待这种实施？
为了确保此问题不会被标记为与stackoverflow无关，我可以问：什么是将业务逻辑与Symfony项目中的实体分开的最佳方法？