Listing
1-1
implementing all the mapping on your own (because at the time of this writing we are not
aware of any powerful ORM tools for PHP that are not based on an ActiveRecord approach).
(1) Note that complexity != size. A domain model can be pretty large without being
complex and vice versa. Obviously, larger domain models have a greater probability of
being complex.
Now you already know a lot about what Doctrine is and what it is not. If you would like to dive
in now and get started right away, jump straight to the next chapter "Getting Started".
Key Concepts
The Doctrine Query Language (DQL) is an object query language. It let's you express queries
for single objects or full object graphs, using the terminology of your domain model: class
names, field names, relations between classes, etc. This is a powerful tool for retrieving or
even manipulating objects without breaking the separation of the domain model (field names,
class names, etc) from the relational model (table names, column names, etc). DQL looks very
much like SQL and this is intended because it makes it relatively easy to grasp for people
knowing SQL. There are, however, a few very important differences you should always keep
in mind:
Take this example DQL query:
FROM User u
LEFT JOIN u.Phonenumbers where u.level > 1
The things to notice about this query:
• We select from classes and not tables. We are selecting from the User class/model.
• We join along associations (u.Phonenumbers)
• We can reference fields (u.level)
• There is no join condition (ON x.y = y.x). The associations between your classes and
how these are expressed in the database are known to Doctrine (You need to make
this mapping known to Doctrine, of course. How to do that is explained later in the
Defining Models (page 51) chapter.).
DQL expresses a query in the terms of your domain model (your classes, the attributes they
have, the relations they have to other classes, etc.).
It's very important that we speak about classes, fields and associations between classes here.
User is not a table / table name . It may be that the name of the database table that the User
class is mapped to is indeed named User but you should nevertheless adhere to this
differentiation of terminology. This may sound nit picky since, due to the ActiveRecord
approach, your relational model is often very similar to your domain model but it's really
important. The column names are rarely the same as the field names and as soon as
inheritance is involved, the relational model starts to diverge from the domain model. You can
have a class User that is in fact mapped to several tables in the database. At this point it
should be clear that talking about "selecting from the User table" is simply wrong then. And
as Doctrine development continues there will be more features available that allow the two
models to diverge even more.
Chapter 1: Introduction 16
-----------------
Brought to you by