Create the DTO system of your dreams
summary
Adds the new state options flag so Doctrine’s collection/item providers and processors remain usable for DTO resources, but reveals problems with changing the request’s central object and missing custom fields and processors. Implements a custom provider/processor that delegates queries and saves to Doctrine, maps entity↔DTO via a small mapper (example: micromapper), preserves pagination and filters, and returns DTOs as the canonical request object — a working, reusable pattern that requires only mapping code.
AI-written summary · about
chapters (12)
- 0:00Introduction and speaker intro
- 1:49What makes a good DTO system
- 2:32Providers and processors explained
- 7:12Why use DTOs over entities
- 9:20DTOs with API resource attribute
- 12:30State options and their limits
- 16:44Making DTO the central object
- 19:08Custom state provider setup
- 21:14Generic DTO state provider
- 25:07Reusable DTO system design
- 29:00Final solution and benefits
- 31:04Summary and thanks
related talks
59mDoctrine ORM Good Practices and Tricks
01h 03mUnbreakable Domain Models
21mLaravel Doctrine: A Data Mapper Approach
40mDoctrine: More Than Just an ORM
59mHow much database abstraction do I need?
56mThe absolute beginner's guide to Domain Driven Design with Symfony
25mCode decoupling from Symfony (and others frameworks)
46mDomain-Driven Design & TYPO3: The missing pieces