WebApp development with Doctrine

WebApp development with Doctrine

Transcript

1. Radosław Zagórski www.linkedin.com/in/radoslawzagorski
2. WebApp development with doctrine
3. What is Doctrine? A group of persistence-oriented libraries for PHP
4. Doctrine Project • Common • Annotations • Cache • Collections • Lexer • Migrations • MongoDB Abstraction Layer • MongoDB Object Document Mapper • PHPCR ODM • Inflector • Object Relational Mapper • Database Abstraction Layer (DBAL)
5. Inflector
6. Database Abstraction Layer (DBAL)
7. Database Abstraction Layer (DBAL)
8. Database Abstraction Layer (DBAL)
9. Database Abstraction Layer (DBAL)
10. Object Relational Mapper
11. Object Relational Mapper
12. KNOW YOUR TOOLS https://www.doctrine-project.org/projects.html
13. What is Doctrine ORM for? • OLTP - Online Transaction Processing • DDD • Fast prototyping • Object Oriented at first
14. What is Doctrine ORM not for? • Dynamic data structures • Reporting • Statistics
15. entities should work without the ORM entities should work without the DB
16. the database is just saving things
17. design entities first define mappings after designing the entities define the database after modeling you domain
19. entities are not typed arrays
20. entities have behaviour
22. remember about the LOD
25. More expressive Easier to test Less coupling More flexible Easier to refactor
26. disallow collection access from outside the entity
28. keep collection hidden in you entities
30. entities should always be valid invalid state should be in a different object (use DTO)
32. avoid setters
33. don’t use lifecycle callbacks
34. avoid coupling with the application layer
36. form components break entity validity
37. avoid auto-generated identifiers
38. Avoid auto-generated identifiers your db operations will block each other you are denying bulk inserts you cannot make multi-request transactions your object is invalid until saved your object does not work without the DB
39. ramsey/uuid
40. AUTO_INCREMENT IS ABUSED FOR SORTING Are you looking for a DATETIME field instead?
41. favour immutable entities
43. Immutable data is simple Immutable data is cacheable (forever) Immutable data is predictable Immutable data enables historical analysis
44. You may want to look at Event Sourcing… (https://github.com/prooph/event-sourcing)
45. avoid soft-deletes
46. Soft Deletes come from an era where keeping everything in a single DB was required
47. break data integrity break immutability break validity
48. Annotations? XML? YAML? Mapping Driver
49. Lazy Loading or Eager Loading? Extra Lazy Loading?
50. use custom repositories
52. query functions are better
54. Separate MyRepository#get() and MyRepository#find()
55. MyRepository#find() can return null MyRepository#get() cannot return null
57. using a get() method that throws, you can simplify error logic
58. DO NOT NORMALIZE DB WITHOUT A NEED FOR IT
59. CONSIDER USING SEPARATE DBS Transactional Data 
 != 
 Reporting Data
60. doctrine paginator isn’t perfect
62. choosing Doctrine does not require you to go all in
63. you can implement 80% of your use cases with Doctrine in a sane way.
65. Thank you!