Doctrine ORM Good Practices and Tricks
summary
Doctrine ORM targets OLTP not reporting and benefits from domain-first design: entities must be valid after construct, use DTOs for form input, favor immutable or append-only models and avoid lifecycle callbacks, bidirectional associations and soft deletes. Practical hacks: use UUIDs for identities so objects work before DB roundtrips (Ben Ramsey library and UUID collision tiny even at 1M/s for 100 years), enable second level cache to speed reads, prefer SQL or custom repositories for heavy queries, and use append-only reads for simple auditing.
AI-written summary · about
chapters (50)
- 0:00Intro
- 0:55DOCTRINE PROJECT A group of persistence-oriented libraries for PHP
- 1:16WE ARE LOOKING FOR CONTRIBUTORS! (Must be prepared to take unpopular decisions)
- 2:28DOCTRINE 2 ORM BEST PRACTICES
- 2:45KNOW YOUR ENEMY
- 4:26OLTP
- 5:36FAST PROTOTYPING
- 6:34DYNAMIC DATA STRUCTURES
- 7:11REPORTING That's what SQL is for It's a QUERY language, after all
- 7:47ENTITIES (OF COURSE) Entities should work without the ORM Entities should work without the DB
- 9:04ENTITIES (MOSTLY) REPRESENT YOUR DOMAIN
- 9:23DESIGN ENTITIES FIRST
- 9:33DEFINE THE DATABASE AFTER MODELING YOUR DOMAIN
- 9:48DEFINE MAPPINGS AFTER DESIGNING THE ENTITIES
- 10:02DESIGNING ENTITIES
- 10:33ENTITIES ARE NOT TYPED ARRAYS
- 10:51ENTITIES HAVE BEHAVIOR
- 11:30ENTITY INTERNAL STATE DESIGN IS IRRELEVANT You can deal with state after designing the API Designing State-first leads to terrible coupling
- 13:46RESPECT THE LOD
- 16:55DISALLOW COLLECTION ACCESS FROM OUTSIDE THE ENTITY
- 20:27STAY VALID AFTER _CONSTRUCT (Regardless of the DB) Named constructors are OK
- 21:11AVOID SETTERS
- 21:27AVOID COUPLING WITH THE APPLICATION LAYER
- 24:04FORM COMPONENTS BREAK ENTITY VALIDITY
- 25:11AVOID LIFECYCLE CALLBACKS
- 30:12AUTO INCREMENT IS ABUSED FOR SORTING Are you looking for a DATETIME field instead?
- 31:09AVOID DERIVED PRIMARY KEYS You are just normalizing for the sake of it Does your domain really NEED it?
- 32:29AVOID COMPOSITE PRIMARY KEYS Any reason to not use an unique constraint instead? Do they make a difference in your domain?
- 33:38FAVOUR IMMUTABLE ENTITIES Or append-only data-structures
- 35:25Immutable data is simple Immutable data is cacheable (forever) Immutable data is predictable Immutable data enables historical analysis
- 36:25AVOID SOFT-DELETES
- 36:54SOFT DELETES BREAK DATA INTEGRITY (and therefore validity)
- 38:20Soft Deletes can usually be replaced with more specific domain concepts
- 39:58MAPPING DRIVER CHOICE
- 40:40USE XML MAPPINGS IN PUBLIC PACKAGES
- 40:57LAZY OR EAGER?
- 41:21EAGER LOADING IS USELESS
- 41:55EXTRA LAZY INDICATES HIGH RISK AREAS We reach the limits of the ORM Careful about performance/transaction size!
- 43:03AVOID BI-DIRECTIONAL ASSOCIATIONS
- 43:23BI-DIRECTIONAL ASSOCIATIONS ARE OVERHEAD
- 44:00USE CUSTOM REPOSITORIES FOR IMPROVED EXPRESSIVENESS
- 45:22REPOSITORIES ARE SERVICES So are Query Functions
- 46:15INJECT REPOSITORIES INSTEAD
- 49:44KEEP NORMALIZATION UNDER CONTROL
- 50:12KEEP NORMALIZATION (FREAKS) UNDER CONTROL
- 50:38You may need to gag your DBAs... Or get them to understand your needs Academic and practical knowledge may differ
- 51:11WHAT ABOUT PERFORMANCE?
- 53:00RECAP
- 53:27DO NOT NORMALIZE WITHOUT A NEED FOR IT Otherwise, you're digging your own grave!
- 53:46CONSIDER USING SEPARATE DBS Transactional Data
related talks
59mHow much database abstraction do I need?
48mORM Iinsights - How to Not Hurt Yourself?
01h 03mUnbreakable Domain Models
36mORM is an Offensive Anti-Pattern
37mDemystifying cache in Doctrine ORM
01h 05mAdvanced Weapons and Tactics
44mORM Insights - How not to hurt yourself?
44mDon't Be a Slave to Doctrine Anymore