Post

Kevin Bond
@zenstruck.com

I've been thinking about this for years. Most Symfony best practices encourage code that's explicit and hard to misuse. Doctrine entities have always felt like a strange exception. There are reasons we do it this way... but I think ObjectMapper changes the equation.

SymfonyCasts@symfonycasts.com

🤔 Your #Doctrine entities are lying to you. Or at least... they might be. We've spent years making required properties nullable so entities can double as form models. #Symfony's new ObjectMapper component has me wondering if there's a better way. symfonycasts.com/blog/honest-...

symfonycasts.comKeeping Doctrine Entities Honest with DTOs and ObjectMapperDoctrine entities in Symfony often double as form models, forcing required properties to become nullable and allowing invalid states required by Symfony forms. Let's explore how DTOs (Data Transfer…

1 repost1 like

Dan Martin
@dan-martin.net

I don't think doctrine entities themselves are the problem. I think binding them directly to forms is (which this helps with). If entities are kept within a persistence layer then things aren't too bad. Separating them also allows for designing a UI that doesn't need to map directly to the database.