Business
Jobs
  • About Us
  • Solutions
    • Job Postings
      Post your job and receive qualified candidates in 48h.
    • Candidate Assessments
      500+ technical and psychological tests, plus anti-fraud.
    • Headhunting
      Tailor-made executive search from start to finish.
    • Payroll + EOR
      Payroll dispersal and EOR across 15+ LATAM countries.
  • Pricing
  • Jobs

0

416
Views
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 answers
Answer question

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 Report

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 Report
Answer question
Find remote jobs

Discover the new way to find a job!

Top jobs
Top job categories
Business
Post vacancy Pricing Sales
Legal
Terms and conditions Privacy policy
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Show me some job opportunities
There's an error!