Provide a method of DI for entities

Is this still actively being pursued or is there a workaround?

@drupals.user There haven't been any updates in 2+ years, so no, it isn't actively being updated.

As a workaround, you can use \Drupal calls without DI.

bhanu951 → changed the visibility of the branch 11.x to hidden.

I used to think DI on entities was a good idea and even implemented a way to do it via overriding the storage class, but I've honestly completely come around to the Typed Entity module approach of using a (very clever) way of wrapping entities; see #26 ( #2142515-26: Provide a method of DI for entities → ). I over-engineered a solution to use DI on node entities, and it turned into a maintenance nightmare on multiple occasions, until I'd had enough and moved all that code to entity wrappers.

Here's the big problem with adding DI to entities: entities are already complex, and this just loads more complexity into them, making them more tedious to test, mock up, etc.

I know the thought of having to add an additional step every time you act on an entity to wrap it may seem annoying - and it certainly held me back for a while - but the benefits end up far outweighing that by allowing you to mock up and test parts of the logic without baking it directly into entity classes. If you want to see a concrete example (and one I'm very proud of), here's an absolutely massive merge request from last year where I did such a refactor to replace overloaded entity class logic with entity wrappers.

I don't totally understand the benefits of Typed Entity approach in #26 -- which is fine! If it works for folks then that is great! (Though I wish there were some bite-sized, practical example on that module page that show the benefits. Your massive MR is...well...massive :D).

But the trouble with is -- per #27 -- this is still a contrib approach. It feels like something that should be addressed in core, if possible, for folks who just want to stick with Core. Whether bundle classes or basic entity classes, we end up with a de facto workaround being to just call \Drupal directly. The alternative being dependency inversion, which works but isn't as nice of DX.

This is actually one of the things OOP hooks could help with. Let's take a look at Drupal\system\Entity\Menu. All of the overridden methods (preDelete(), save(), delete()) could be extracted to a hook class.

So, my suggestion would be to first try to reduce close coupling of entities with services by leveraging OOP hooks or the event system (whatever works best for the given entity type).

@znerol yesh I think you're correct for some cases but not all. For instance in Drupal Commerce, Order entities have this:

  /**
   * {@inheritdoc}
   */
  public function getCalculationDate() {
    $timezone = $this->getStore()?->getTimezone();
    $timestamp = $this->getPlacedTime() ?: \Drupal::time()->getRequestTime();
    $date = DrupalDateTime::createFromTimestamp($timestamp, $timezone);

    return $date;
  }

It's just a standard method unrelated to entity lifecycle.

Yes, sure. I am suggesting incremental improvements.

I have mixed opinions on this.

One one side, DI for things that are being serialized has some problematic drawbacks (and entities are serialized _a lot_), it requires trickery such as DependencySerializationTrait. And there's discussions around whether or not entities should be value object, which would imply they shouldn't do stuff that requires DI.

But also, we have bundle classes now (although they probably mostly serve as nice getters and setters), pre/post methods (Re #48, Hooks being services changes things bit, but I still generally prefer to have entity related logic on the entity itself) and ContentEntityBase itself has a number of \Drupal:: calls.

One problem is that, unlike other plugins, we never got the factory stuff working, so we don't have a single thing responsible for creating entity objects. We did make it work for bundle classes though, it's fairly well isolated in the storage handler.

To summarize, not against it, but I do very much expect that there will be cases where it will come back to bite us.

@mrweiner I know it's contrib and I would love it to go into core, but I don't feel like that's a downside - a lot of really awesome and super useful things are implemented in contrib, prove their worth there, and are adopted into core. The biggest benefit in using Typed Entity (in my opinion) is that you now have a clean separation of your data (entities, their fields) and the logic that allows you to interact with it (the wrapped entity plug-ins), which leads to more testable code and hopefully away from spaghetti code.

@berdir That's also a good point that entities are serialized/deserialized a lot which adds even more potential headaches.