Empresas
Empleos
  • Sobre nosotros
  • Soluciones
    • Publicación de vacantes
      Publica tu vacante y recibe candidatos calificados en 48h.
    • Evaluación de candidatos
      500+ pruebas técnicas y psicológicas, más anti-fraude.
    • Headhunting
      Búsqueda ejecutiva a la medida de principio a fin.
    • Nómina + EOR
      Dispersión de nómina y EOR en más de 15 países de LATAM.
  • Precios
  • Empleos

0

415
Vistas
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 Respuestas
Responde la pregunta

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 Denunciar

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 Denunciar
Responde la pregunta
Encuentra empleos remotos

¡Descubre la nueva forma de encontrar empleo!

Top de empleos
Top categorías de empleo
Empresas
Publicar vacante Precios Comercial
Legal
Términos y condiciones Política de privacidad
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomiéndame algunas ofertas
Necesito ayuda