Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

410
Visualizações
Symfony : is it bad practice to add custom functions in an Entity?

I understand that an Entity is a basic class that holds data.

But is it bad practice if the Entity has custom functions that manipulates the data ?

I personally think that this kind of functions should go into a different Service. But in this case, the getNextPayroll is quite useful :

<?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;
    }


}

The date of the next payroll is not stored in database. Only the date of the last payroll. Should I get the next payroll date in a different service or is it OK to use use a custom function non-generated by doctrine in an entity ?

over 4 years ago · Santiago Trujillo
2 Respostas
Responde à pergunta

0

It's not a bad practice, if your code still satisfies SOLID principles (mainly, Single Responsibility principe in that case)

So, if the method isn't related to entity logic (for example, sending emails or persisting something to database right from your entity) -- it's wrong. Otherwise, it's absolutely OK.

The major attribute of the logic related to entity -- it should be in the same layer with another stuff in the entity.

Actually, Doctrine entities is not just Data Transfer Objects (without behavior). Doctrine's developers insist using the entities as Rich Models (look the video by Marco Pivetta, one of Doctrine's developers and see his nice presentation)

over 4 years ago · Santiago Trujillo Relatório

0

As far as I know it shouldn't be bad practice as long as your entity doesn't get into the Database layer, which the Repository should take care of.

So things where you more or less just get EntityData back (like your method which returns just modified data that belongs to the Entity) should be fine in the Entity it self. This way you also easily use the methods inside Twig, which automaticaly searchs for the method name (ex. {{ User.name }} will search for User->getName() and if it doesn't find it, it will search for User->name())

If you reusing this part and want to be dynamic, it also could be a good idea to create a custom Twig extension.

I think you will only need a service if you going to do very complicated things where you actually also need to inject the EntityManager and also retrive data from other entities that maybe are not part of the usual relations.

over 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda