Question

我理解Entity是一个保存数据的基本类。

但如果实体具有操纵数据的自定义函数，这是不好的做法吗？

我个人认为这种功能应该进入不同的Service。但在这种情况下，getNextPayroll非常有用：

<?php
class Payroll
{
    /**
     * @var int
     *
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;

    /**
     * @var \DateTime
     *
     * @ORM\Column(name="last_payroll", type="datetime", nullable = true)
     */
    private $lastPayroll;

    /**
     * Set lastPayroll
     *
     * @param \DateTime $lastPayroll
     * @return CompanyBase
     */
    public function setLastPayroll($lastPayroll)
    {
        $this->lastPayroll = $lastPayroll;

        return $this;
    }

    /**
     * Get lastPayroll
     *
     * @return \DateTime 
     */
    public function getLastPayroll()
    {
        return $this->lastPayroll;
    }

    public function getNextPayroll()
    {
        $payrollNext = clone $this->getLastPayroll();
        $payrollNext->add(new \DateInterval("P1M"));

        return $payrollNext;
    }


}

下一个工资核算的日期未存储在数据库中。仅限上一个工资单的日期。我应该在不同的服务中获得下一个工资核算日期，还是可以使用在实体中使用非由理论生成的自定义函数？

Answer 1

如果你的代码仍然满足SOLID原则（主要是那种情况下的单一责任原则），这不是一个坏习惯。

因此，如果该方法与实体逻辑无关（例如，直接从您的实体发送电子邮件或将某些内容保存到数据库中） - 那就错了。否则，它绝对没问题。

与实体相关的逻辑的主要属性 - 它应与实体中的其他内容位于同一层。

实际上，Doctrine实体不仅仅是数据传输对象（没有行为）。 Doctrine的开发人员坚持使用这些实体作为Rich Models（由Doctrine开发人员之一Marco Pivetta看the video并查看他的nice presentation）

Answer 2

据我所知，只要您的实体没有进入数据库层（存储库应该处理），这不应该是不好的做法。

所以你或多或少只是让EntityData返回的东西（就像你的方法只返回属于Entity的修改过的数据一样）在它自己的实体中应该没问题。这样你也可以轻松使用Twig中的方法，自动搜索方法名称（例如{{ User.name }}将搜索User->getName()，如果找不到它，它将搜索{{1} }}）

如果您重复使用此部件并希望保持动态，那么创建自定义Twig扩展也是一个好主意。

我认为你只需要一个服务，如果你要做一些非常复杂的事情，你实际上也需要注入EntityManager，并从其他实体中检索可能不属于通常关系的数据。

Symfony：在实体中添加自定义函数是不好的做法吗？

2 个答案: