Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Newer
Older
100644 128 lines (93 sloc) 4.34 kB
a5a0dfa @beberlei Converted ORM Docs into ReST
beberlei authored
1 Best Practices
2 ==============
3
4 The best practices mentioned here that affect database
5 design generally refer to best practices when working with Doctrine
6 and do not necessarily reflect best practices for database design
7 in general.
1bfeaf3 @beberlei Initial conversion from Markdown to ReST - Finalized Cookbook
beberlei authored
8
9
10 Don't use public properties on entities
11 ---------------------------------------
12
13 It is very important that you don't map public properties on
14 entities, but only protected or private ones. The reason for this
15 is simple, whenever you access a public property of a proxy object
16 that hasn't been initialized yet the return value will be null.
17 Doctrine cannot hook into this process and magically make the
18 entity lazy load.
19
20 This can create situations where it is very hard to debug the
21 current failure. We therefore urge you to map only private and
22 protected properties on entities and use getter methods or magic
23 \_\_get() to access them.
24
25 Constrain relationships as much as possible
26 -------------------------------------------
27
28 It is important to constrain relationships as much as possible.
29 This means:
30
31
32 - Impose a traversal direction (avoid bidirectional associations
33 if possible)
34 - Eliminate nonessential associations
35
36 This has several benefits:
37
38
39 - Reduced coupling in your domain model
40 - Simpler code in your domain model (no need to maintain
41 bidirectionality properly)
42 - Less work for Doctrine
43
44 Avoid composite keys
45 --------------------
46
47 Even though Doctrine fully supports composite keys it is best not
48 to use them if possible. Composite keys require additional work by
49 Doctrine and thus have a higher probability of errors.
50
51 Use events judiciously
52 ----------------------
53
54 The event system of Doctrine is great and fast. Even though making
55 heavy use of events, especially lifecycle events, can have a
56 negative impact on the performance of your application. Thus you
57 should use events judiciously.
58
59 Use cascades judiciously
60 ------------------------
61
62 Automatic cascades of the persist/remove/merge/etc. operations are
63 very handy but should be used wisely. Do NOT simply add all
64 cascades to all associations. Think about which cascades actually
65 do make sense for you for a particular association, given the
66 scenarios it is most likely used in.
67
68 Don't use special characters
69 ----------------------------
70
71 Avoid using any non-ASCII characters in class, field, table or
72 column names. Doctrine itself is not unicode-safe in many places
73 and will not be until PHP itself is fully unicode-aware (PHP6).
74
75 Don't use identifier quoting
76 ----------------------------
77
78 Identifier quoting is a workaround for using reserved words that
79 often causes problems in edge cases. Do not use identifier quoting
80 and avoid using reserved words as table or column names.
81
82 Initialize collections in the constructor
83 -----------------------------------------
84
85 It is recommended best practice to initialize any business
86 collections in entities in the constructor. Example:
87
4698346 @beberlei Finialized ReST doc changes, merged changes from latest Markdown docs.
beberlei authored
88 .. code-block:: php
1bfeaf3 @beberlei Initial conversion from Markdown to ReST - Finalized Cookbook
beberlei authored
89
90 <?php
91 namespace MyProject\Model;
92 use Doctrine\Common\Collections\ArrayCollection;
93
94 class User {
95 private $addresses;
96 private $articles;
97
98 public function __construct() {
99 $this->addresses = new ArrayCollection;
100 $this->articles = new ArrayCollection;
101 }
102 }
103
104 Don't map foreign keys to fields in an entity
105 ---------------------------------------------
106
107 Foreign keys have no meaning whatsoever in an object model. Foreign
108 keys are how a relational database establishes relationships. Your
109 object model establishes relationships through object references.
110 Thus mapping foreign keys to object fields heavily leaks details of
111 the relational model into the object model, something you really
112 should not do.
113
114 Use explicit transaction demarcation
115 ------------------------------------
116
117 While Doctrine will automatically wrap all DML operations in a
118 transaction on flush(), it is considered best practice to
119 explicitly set the transaction boundaries yourself. Otherwise every
120 single query is wrapped in a small transaction (Yes, SELECT
121 queries, too) since you can not talk to your database outside of a
122 transaction. While such short transactions for read-only (SELECT)
123 queries generally don't have any noticeable performance impact, it
124 is still preferable to use fewer, well-defined transactions that
125 are established through explicit transaction boundaries.
126
127
Something went wrong with that request. Please try again.