What do you get with Print?

Instant access to your digital copy whilst your Print order is Shipped

Paperback book shipped to your preferred address

Redeem a companion digital copy on all Print orders

Access this title in our online reader with advanced features

DRM FREE - Read whenever, wherever and however you want

Persistence in PHP with Doctrine ORM

Chapter 1. Getting Started with Doctrine 2

The Doctrine project is a collection of libraries providing utilities to ease data persistence in PHP applications. It makes it possible to create complex model layers in no time that will be compatible with popular DBMS, including SQLite, MySQL, and PostgreSQL. To discover and understand Doctrine, we will create a small blog from scratch throughout this book that will mainly use the following Doctrine components:

Common provides utilities that are not in the PHP standard library including a class autoloader, an annotations parser, collections structures, and a cache system.
Database Abstraction Layer (DBAL) exposes a unique interface to access popular DBMS. Its API is similar to PDO (and PDO is used when possible). The DBAL component is also able to execute the same SQL query on different DBMS by internally rewriting the query to use specific constructs and emulate missing features.
Object Relational Mapper (ORM) allows accessing and managing relational database tables and rows through an object-oriented API. Thanks to it, we will directly manipulate PHP objects, and it will transparently generate SQL queries to populate, persist, update, and delete them. It is built on top of DBAL and will be the main topic of this book.

Note

For more information on PHP Data Objects and the data-access abstraction layer provided by PHP, refer to the following link: http://php.net/manual/en/book.pdo.php

To learn Doctrine, we will build together a tiny blog engine with advanced features such as the following:

Posts list, creation, editing, and deletion
Comments
Tag filtering
Profiles for author of posts and comments
Statistics
Data fixtures

The following is a screenshot of the blog:

In this chapter, we will learn about the following topics:

Understanding concepts behind Doctrine
Creating the project's structure
Installing Composer
Installing Doctrine ORM, DBAL, and Common through Compose
Bootstrapping the app
Using Doctrine's Entity Manager
Configuring Doctrine command-line tools

Understanding the concepts behind Doctrine

Doctrine ORM implements Data Mapper and Unit of Work design patterns.

The Data Mapper is a layer designed to synchronize data stored in database with their related objects of the domain layer. In other words, it does the following:

Inserts and updates rows in the database from data held by object properties
Deletes rows in the database when related entities are marked for deletion
Hydrates in-memory objects with data retrieved from the database

Note

For more information about the Data Mapper and Unit of Work design patterns, you can refer to the following links: http://martinfowler.com/eaaCatalog/dataMapper.html and http://martinfowler.com/eaaCatalog/unitOfWork.html

In the Doctrine terminology, a Data Mapper is called an Entity Manager. Entities are plain old PHP objects of the domain layer.

Thanks to the Entity Manager, they don't have to be aware that they will be stored in a database. In fact, they don't need to be aware of the existence of the Entity Manager itself. This design pattern allows reusing entity classes regardless of the persistence system.

For performance and data consistency, the Entity Manager does not sync entities with the database each time they are modified. The Unit of Work design pattern is used to keep the states of objects managed by the Data Mapper. Database synchronization happens only when requested by a call to the flush() method of the Entity Manager and is done in a transaction (if something goes wrong while synchronizing entities to the database, the database will be rolled back to its state prior to the synchronization attempt).

Imagine an entity with a public $name property. Imagine the following code being executed:

  $myEntity->name = 'My name';
  $myEntity->name = 'Kévin';
  $entityManager->flush($myEntity);

Thanks to the implementation of the Unit of Work design pattern, only one SQL query similar to the following will be issued by Doctrine:

      UPDATE MyEntity SET name='Kévin' WHERE id=1312;

Note

The query is similar because, for performance reasons, Doctrine uses prepared statements.

We will finish the theory part with a short overview of the Entity Manager methods and their related entity states.

The following is an extract of a class diagram representing an entity and its Entity Manager:

The find() method hydrates and returns an entity of the type passed in the first parameter having the second parameter as an identifier. Data is retrieved from the database through a SELECT query. The state of this returned entity is managed. It means that when the flush() method is called, changes made to it will be synced to the database. The find() method is a convenience method that internally uses an entity repository to retrieve data from the database and hydrate the entity. The state of the managed entities can be changed to detached by calling the detach() method. Modifications made to the detached entity will not be synced to the database (even when the flush() method is called) until its state is set back to managed with a call to the merge() method.
Note
The start of Chapter 3, Associations, will be dedicated to entity repositories.
The persist() method tells Doctrine to set the state of the entity passed in parameter as managed. This is only useful for entities that have not been synced at least one time to the database (the default state of a newly created object is new) because entities hydrated from existing data automatically have the managed state.
The remove() method sets the state of the passed in entity to removed. Data related to this entity will be effectively removed from the database with a DELETE SQL query the next time the flush() method is called.
The flush() method syncs data of entities with managed and removed states to the database. Doctrine will issue INSERT, UPDATE, and DELETE SQL queries for the sync. Before that call, all changes are only in-memory and are never synchronized to the database.

Note

Doctrine's Entity Manager has a lot of other useful methods documented on the Doctrine website, http://www.doctrine-project.org/api/orm/2.4/class-Doctrine.ORM.EntityManager.html.

This is abstract for now, but we will understand better how the Entity Manager works with numerous examples throughout the book.

Installing Doctrine

The following steps should be performed to install Doctrine:

To install Doctrine, we need to create a file called composer.json in our new blog directory. It lists dependencies of our project as shown in the following code:
```
{
    "name": "myname/blog",
    "type": "project",
    "description": "My small blog to play with Doctrine",

    "require": {
        "doctrine/orm": "2.4.*"
    },

    "autoload": {
        "psr-0": { "": "src/" }
    }
} 
```
This standard JSON file will be parsed by Composer to download and install all dependencies specified. Once installed, Composer will load all classes of these libraries automatically.
The name, type, and description attributes are optional but it's a good practice to always fill them. They provide general information about the project we are working on.
The more interesting part of this composer.json file is the require field. In order to get it installed by Composer, all libraries used by our app must be listed here. A lot of PHP libraries are available on Packagist, the default Composer package repository. Of course, it's the case of Doctrine projects.
Note
For more information on Packagist, go through the following link: https://packagist.org/
We indicate that we need the latest minor release of the 2.4 branch of Doctrine ORM. You can set a major or minor version here, and even more complicated things.
Note
For more information on a package version, you can refer to the following link: http://getcomposer.org/doc/01-basic-usage.md#package-versions
The autoload field is here to tell Composer to automatically load classes of our app. We will put our specific code in a directory called src/. Our files and classes will follow the PSR-0 namespacing and file-naming standard.
Note
PHP Specification Requests are attempts to improve interoperability of PHP applications and libraries. They are available at http://www.php-fig.org/.
It's time to use Composer to install the ORM. Run the following command:
```
    php composer.phar install
```
New files appear in the vendor/ directory. Doctrine ORM has been installed, and Composer was smart enough to get all its dependencies, including Doctrine DBAL and Doctrine Common.
A composer.lock file has also been created. It contains exact versions of installed libraries. This is useful for deploying applications. Thanks to this file, when running the install command, Composer will be able to retrieve the same versions that have been used in the development.
Doctrine is now properly installed. Easy, isn't it?
To update libraries when there are new releases in the 2.4 branch, we just need to type the following command:
```
    php composer.phar update
```

Bootstrapping the app

The following steps need to be performed for bootstrapping the app:

Create a new file called config/config.php that will contain configuration parameters of our app as shown in the following code:
```
  <?php

  // App configuration
  $dbParams = [
    'driver' => 'pdo_sqlite',
    'path' => __DIR__.'/../data/blog.db'
  ];

  // Dev mode?
  $dev = true;
```
The Doctrine configuration parameters are stored in the $dbParams array. We will use a SQLite Database called blog.db stored in the data/ directory. If you want to use MySQL or any other DBMS, it's here that you will configure the driver to use, the database name, and the access credentials.
Note
The following is a sample configuration to use MySQL instead of SQLite:
```
$dbParams = [
    'driver' => 'pdo_mysql',
    'host' => '127.0.0.1',
    'dbname' => 'blog',
    'user' => 'root',
    'password' => ''
];
```
Config keys are self-explanatory.
If the $dev variable is true, some optimizations will be disabled to ease debugging. Disabling the dev mode allows Doctrine to put a lot of data such as metadata in powerful caches to increase overall performances of the app.
Note
It requires cache driver installation and extra configuration, which is available at http://docs.doctrine-project.org/en/latest/reference/caching.html.
Next, we need a way to bootstrap our app. Create a file called bootstrap.php in the src/ directory. This file will load everything we need as given in the following code:
```
  <?php

  require_once __DIR__.'/../vendor/autoload.php';
  require_once __DIR__.'/../config/config.php';
```
The first line requires the Composer autoloader. It allows you to automatically load the Doctrine's classes, the project's classes (that will be in the src/ directory), and any class of a library installed with Composer.
The second line imports the configuration file of the app. The project structure is created and the initialization process of the app is done. We are ready to start using Doctrine.

Using Doctrine's Entity Manager

The principle of an ORM is to manage data stored in a relational database through an object-oriented API. We learned about its underlying concepts earlier in this chapter.

Each entity class is mapped to the related database table. Properties of the entity class are mapped to the table's columns.

So, the rows of a database table are represented in the PHP app by a collection of entities.

Doctrine ORM is able to retrieve data from the database and to populate entities with them. This process is called hydration.

Note

Instead of entities, Doctrine can populate PHP arrays in different manners (with the object graph, with a rectangular result set, and so on). It is also possible to create custom hydrators by referring to the following link: http://docs.doctrine-project.org/en/latest/reference/dql-doctrine-query-language.html#hydration-modes

As we have learned with the Data Mapper design pattern, it also does the inverse job: it persists data held by entities to database.

We will play a lot with entities later.

Doctrine comes with the following files to map entities to tables:

Annotations in comment blocks that embed directly in the entities
XML configuration files
YAML configuration files
Plain PHP files

Annotations are fairly recent in the PHP world (they are popular in Java) but they are already widely used by Doctrine and Symfony communities. The advantages of this method are great readability and maintenance facility because mapping information is next to the PHP code. Putting mapping information directly in the code can also be a drawback in some contexts, especially for big projects that use several persistence systems.

We will use the annotation method in this book, but other methods are described in the Doctrine documentation. We will return to them in Chapter 2, Entities and Mapping Information.

In the next chapter, Chapter 2, Entities and Mapping Information, we will discover that Doctrine is smart enough to use mapping information to automatically create the related database schema.

For now, we will focus on retrieving an Entity Manager. As entities are retrieved, persisted, updated, and removed through it, this is the entry point of Doctrine ORM.

Edit the src/bootstrap.php file to retrieve a Doctrine's Entity Manager. Add the following code at the end of this file:

  $entitiesPath = array(__DIR__.'/Blog/Entity');
  $config = Setup::createAnnotationMetadataConfiguration    ($entitiesPath, $dev);
  $entityManager = EntityManager::create($dbParams, $config);

Tip

Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

The $entitiesPath property contains the list of paths to directories storing entity classes. We already mentioned that our app will follow the PSR-0 namespacing convention. The \Blog folder will be the root namespace and entity classes will be in the \Blog\Entity folder.

A Doctrine configuration is created to use annotations for mapping information and to be able to locate the blog's entities that we'll create.

A new EntityManager is created and configured to use our database and Doctrine settings.

For simplicity, we create a unique Entity Manager that will be used across the application. For real-world apps, you should take a look at the Dependency Injection design pattern.

Note

Find more on Dependency Injection pattern at the following link: http://en.wikipedia.org/wiki/Dependency_injection

Key benefits

Develop a fully functional Doctrine-backed web application

Demonstrate aspects of Doctrine using code samples

Generate a database schema from your PHP classes

Description

Doctrine 2 has become the most popular modern persistence system for PHP. It can either be used as a standalone system or can be distributed with Symfony 2, and it also integrates very well with popular frameworks. It allows you to easily retrieve PHP object graphs, provides a powerful object-oriented query language called DQL, a database schema generator tool, and supports database migration. It is efficient, abstracts popular DBMS, and supports PHP 5.3 features. Doctrine is a must-have for modern PHP applications. Persistence in PHP with Doctrine ORM is a practical, hands-on guide that describes the full creation process of a web application powered by Doctrine. Core features of the ORM are explained in depth and illustrated by useful, explicit, and reusable code samples. Persistence in PHP with Doctrine ORM explains everything you need to know to get started with Doctrine in a clear and detailed manner. From installing the ORM through Composer to mastering advanced features such as native queries, this book is a full overview of the power of Doctrine. You will also learn a bunch of mapping annotations, create associations, and generate database schemas from PHP classes. You will also see how to write data fixtures, create custom entity repositories, and issue advanced DQL queries. Finally it will teach you to play with inheritance, write native queries, and use built-in lifecycle events. If you want to use a powerful persistence system for your PHP application, Persistence in PHP with Doctrine ORM is the book you.

Who is this book for?

This book is primarily intended for PHP developers and architects who want to increase their skills in the field of Persistence and ORM to map the data they are working on to objects they are using in programming. Basic knowledge of databases and PDO and working knowledge of PHP namespaces is a prerequisite.

What you will learn

Install Doctrine through the Composer dependency manager

Configure Doctrine Command Line Tools

Learn to manage relations between entities with different association types

Create data fixtures, a custom entity repository, and native SQL queries

Master the query builder to generate DQL queries

Get started with inheritance and lifecycle events

What do you get with Print?

Instant access to your digital copy whilst your Print order is Shipped

Paperback book shipped to your preferred address

Redeem a companion digital copy on all Print orders

Access this title in our online reader with advanced features

DRM FREE - Read whenever, wherever and however you want

Frequently bought together

Extending Symfony2 Web Application Framework

S$52.99

S$74.99

S$44.99

Total S$ 172.97

M. Finnerty Jr. Nov 22, 2015

Great book. Well written. I would recommend this book to anyone staring with ORM's

Amazon Verified review

Derek J. Lambert Mar 13, 2014

If you're looking for a definitive, all-encompassing API reference for the Doctrine libraries this book most likely won't meet your needs. For those discovering the power and freedom provided by the Doctrine ORM library for the first time or struggling to put all the pieces together using project documentation, Stack Overflow, and the other usual suspects - this book is for you! Throw in a little object-orientated PHP and you're well on your way to building a functional, usable, and extendable application.Dunglas begins with a brief but sufficient stop explaining the prerequisites for a modern PHP 5.4+ project, utilizing Composer to provide the Doctrine 2.4 and related dependencies. As he builds a mock application the code samples are provided in the context of a plausible real-world use scenario, and built upon while progressing through the entire object graph. This perspective provides a clear understanding of object associations and collections.Dunglas goes on to describe using entity repositories and Query Builder to access and manipulate stored entities, continuing into the Doctrine Query Language (DQL) for custom queries. He finishes off exploring some of the advanced functionality provided including object inheritance, events, and native queries.While the subject of unit tests are never touched, functional testing is covered within the scope of the ever useful data fixture. A plethora of additional advanced and tangential subjects, while beyond the extent of the text, are brought up in context with a brief summary and URL for authoritative documentation allowing further exploration into unlimited possibilities.Persistence in PHP with Doctrine ORM fills a long lacking void and provides a coherent and fluent tutorial on the current Doctrine 2 codebase. I can’t imagine where I’d be on my current projects had I started with an up to date reference a couple years ago!

J Aug 03, 2015

This was one of the best technical books I've read. The author did a remarkable job at keeping the depth at the just the right level where you gain understanding, but not get bored of needless details.

proappstore Jan 20, 2020

Straight forward. Excellent!

A. Zubarev Feb 16, 2014

In short, Persistence in PHP with Doctrine ORM is a book about harnessing the power of Doctrine ORM, but also:Will let you build a working project using Doctrine involving advanced techniques;Will guard you from doing mistakes early in your getting known Doctrine, andWill advocate on appropriate technologies to use in addition in case your next creation is going to see the world.I would recommend this book to a developer who worked with PHP already, but getting ready to embark onto a more intensive data processing endeavor.The book is not terribly long, yet comprehensive enough to allow a person to become proficient in Doctrine say overnight (yes, my Kindle app estimated my reading speed at ~ 2.5 Hrs, that is without me experimenting with code). Personally, I value concise books because they give me a push and allow a relatively comfortable solo sailing with an occasional exploration of a topic I did not encounter learning but stumbled upon doing real-life work.As an aside, use of an ORM (not just Doctrine specifically) is typically being perceived as a negative phenomenon by the data people (disclaimer: I am the data person), unsurprisingly Kevin mentions performance implications under the so called Big Data scenario. This has it’s grounds, I agree, as for example tuning DML or data retrieval, so let’s not argue here, but at least one aspect on an ORM not possible to beat – is its ability to allow seamless transition from one database platform to another, relatively uncommon in the past, seems to being picking up nowadays. But do not be overly optimistic, no migration is ever smooth, it just alleviates some of the pains and minimizes the costs of engineering and maintaining your software.On the not so bright side the author does not cover executing stored procedures/packages, and apparently Doctrine (as most OSS projects) has a long list of defects, yeah, I can hear you, this is a book review, nothing else, ditto.So one last interesting discovery, the Doctrine community focuses more and more on a NoSQL, Mongo in particular, which is thrilling.You will find information in the book on how to build your own SQL, implement association, inheritance and even a not so often used many-to-many relationships.On the odd note, I saw a circular reference created in one of the book examples, while possible it is very dangerous! Also the book covers only one approach: building your app code-first: meaning the database schema is created after a class, which I (you know who am I Smile) don’t endorse, alas I am / was new to Doctrine.I suggest Kevin adds to ver. 2.0 of this book the following:Building an application the schema-up way, too, andProvide an example where Doctrine is using a Mongo database.I give this book a 5 out of 5 rating because it has achieve its objectives, however it seems that Packt could give it the “Instant” moniker due to its material coverage.

Persistence in PHP with Doctrine ORM: This book is designed for PHP developers and architects who want to modernize their skills through better understanding of Persistence and ORM. You'll learn through explanations and code samples, all tied to the full development of a web application.

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Key benefits

Description

Who is this book for?

What you will learn

Product Details

What do you get with Print?

Contact Details

Shipping Address

Billing Address

Product Details

Packt Subscriptions

Frequently bought together

Table of Contents

Recommendations for you

Customer reviews

People who bought this also bought

About the author

FAQs