Главная
Study mode:
on
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
Description:
Explore best practices and advanced techniques for using Doctrine ORM effectively in PHP applications. Learn how to design entities, handle data persistence, and optimize performance in this comprehensive talk from the PHP UK Conference. Discover the advantages and disadvantages of various approaches to application design with Doctrine ORM, including entity modeling, mapping strategies, and database design considerations. Gain insights into avoiding common pitfalls, such as overuse of soft deletes and bi-directional associations, while learning to leverage features like immutable entities and custom repositories. Understand the importance of domain-driven design and how to balance normalization with practical needs. Improve your Doctrine ORM skills and create more efficient, maintainable PHP applications.

Doctrine ORM Good Practices and Tricks

PHP UK Conference
Add to list
#Conference Talks #PHP UK Conference #Programming #Programming Languages #PHP #Doctrine #Software Development #Application Design #Computer Science #Information Technology #Data Management #Data Integrity #Databases #Database Design #Database Modeling
0:00 / 0:00
1 of 55

Intro