Completed
EXTRA LAZY INDICATES HIGH RISK AREAS We reach the limits of the ORM Careful about performance/transaction size!
Class Central Classrooms beta
YouTube videos curated by Class Central.
Classroom Contents
Doctrine ORM Good Practices and Tricks
Automatically move to the next video in the Classroom when playback concludes
- 1 Intro
- 2 DOCTRINE PROJECT A group of persistence-oriented libraries for PHP
- 3 WE ARE LOOKING FOR CONTRIBUTORS! (Must be prepared to take unpopular decisions)
- 4 DOCTRINE 2 ORM BEST PRACTICES
- 5 KNOW YOUR ENEMY
- 6 OLTP
- 7 FAST PROTOTYPING
- 8 DYNAMIC DATA STRUCTURES
- 9 REPORTING That's what SQL is for It's a QUERY language, after all
- 10 ENTITIES (OF COURSE) Entities should work without the ORM Entities should work without the DB
- 11 ENTITIES (MOSTLY) REPRESENT YOUR DOMAIN
- 12 THE DATABASE IS JUST SAVING THINGS
- 13 DESIGN ENTITIES FIRST
- 14 DEFINE THE DATABASE AFTER MODELING YOUR DOMAIN
- 15 DEFINE MAPPINGS AFTER DESIGNING THE ENTITIES
- 16 DESIGNING ENTITIES
- 17 ENTITIES ARE NOT TYPED ARRAYS
- 18 ENTITIES HAVE BEHAVIOR
- 19 ENTITY INTERNAL STATE DESIGN IS IRRELEVANT You can deal with state after designing the API Designing State-first leads to terrible coupling
- 20 RESPECT THE LOD
- 21 DISALLOW COLLECTION ACCESS FROM OUTSIDE THE ENTITY
- 22 STAY VALID AFTER _CONSTRUCT (Regardless of the DB) Named constructors are OK
- 23 AVOID SETTERS
- 24 AVOID COUPLING WITH THE APPLICATION LAYER
- 25 FORM COMPONENTS BREAK ENTITY VALIDITY
- 26 AVOID LIFECYCLE CALLBACKS
- 27 LIFECYCLE CALLBACKS ARE A PERSISTENCE HACK
- 28 AUTO INCREMENT IS ABUSED FOR SORTING Are you looking for a DATETIME field instead?
- 29 AVOID DERIVED PRIMARY KEYS You are just normalizing for the sake of it Does your domain really NEED it?
- 30 AVOID COMPOSITE PRIMARY KEYS Any reason to not use an unique constraint instead? Do they make a difference in your domain?
- 31 FAVOUR IMMUTABLE ENTITIES Or append-only data-structures
- 32 Immutable data is simple Immutable data is cacheable (forever) Immutable data is predictable Immutable data enables historical analysis
- 33 AVOID SOFT-DELETES
- 34 SOFT DELETES ARE A BROKEN IDEA
- 35 SOFT DELETES BREAK DATA INTEGRITY (and therefore validity)
- 36 Soft Deletes can usually be replaced with more specific domain concepts
- 37 MAPPING DRIVER CHOICE
- 38 USE ANNOTATIONS IN PRIVATE PACKAGES
- 39 USE XML MAPPINGS IN PUBLIC PACKAGES
- 40 LAZY OR EAGER?
- 41 EAGER LOADING IS USELESS
- 42 EXTRA LAZY INDICATES HIGH RISK AREAS We reach the limits of the ORM Careful about performance/transaction size!
- 43 AVOID BI-DIRECTIONAL ASSOCIATIONS
- 44 BI-DIRECTIONAL ASSOCIATIONS ARE OVERHEAD
- 45 USE CUSTOM REPOSITORIES FOR IMPROVED EXPRESSIVENESS
- 46 REPOSITORIES ARE SERVICES So are Query Functions
- 47 INJECT REPOSITORIES INSTEAD
- 48 KEEP NORMALIZATION UNDER CONTROL
- 49 KEEP NORMALIZATION (FREAKS) UNDER CONTROL
- 50 You may need to gag your DBAs... Or get them to understand your needs Academic and practical knowledge may differ
- 51 WHAT ABOUT PERFORMANCE?
- 52 RECAP
- 53 DOMAIN FIRST
- 54 DO NOT NORMALIZE WITHOUT A NEED FOR IT Otherwise, you're digging your own grave!
- 55 CONSIDER USING SEPARATE DBS Transactional Data
