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.

As explained in Chapter 1, Getting Started with Doctrine 2, a Doctrine entity is just a PHP object that will be saved in the database. Doctrine annotations are added in the PHP DocBlock comments of the Entity class properties. Annotations are used by Doctrine to map the object to the related database's table and properties to columns.

Each entity, once persisted through Doctrine, will be related to a row of the database's table.

Create a new file Post.php containing our entity class in the src/Blog/Entity/ location with the following code:

  <?php

  namespace Blog\Entity;

  use Doctrine\ORM\Mapping\Entity;
  use Doctrine\ORM\Mapping\Table;
  use Doctrine\ORM\Mapping\Index;
  use Doctrine\ORM\Mapping\Id;
  use Doctrine...

Doctrine command-line tools that we configured in Chapter 1, Getting Started with Doctrine 2, include a useful command that generates getter and setter methods of an Entity class for us. We will use it to save us from having to write those of the Post class.

Run the following command to generate getters and setters of all entity classes of the application:

  php vendor/bin/doctrine.php orm:generate:entities src/

Post is a simple class with four properties. The setter for $id isn't actually generated. Doctrine populates the $id instance variable directly in the entity hydration phase. We will see later how we delegate the ID generation to the DBMS.

Doctrine annotations are imported from the \Doctrine\ORM\Mapping namespace with use statements. They are used in DocBlocks to add mapping information to the class and its properties. DocBlocks are just a special kind of comment starting with /**.

Doctrine Mapping Types used in the @Column annotation are neither SQL types nor PHP types but they are mapped to both. For instance, the Doctrine text type will be casted to the string PHP type in the entity and stored in a database column with the CLOB type.

The following is a correspondence table for Doctrine Mapping Type of PHP type and SQL type:

Doctrine is smart enough to generate the database schema corresponding to the entity mapping information.

To do this, we will again use Command-Line Tools installed in the first chapter. Type this command in the root directory of our project:

  php vendor/bin/doctrine.php orm:schema-tool:create

The following text must be printed in the terminal:

ATTENTION: This operation should not be executed in a production environment.

Creating database schema...

Database schema created successfully!

A new table called Post has been created in the database. You can use the SQLite client to show the structure of the generated table:

  sqlite3 data/blog.db ".schema Post"

It should return the following query:

  CREATE TABLE Post (id INTEGER NOT NULL, title VARCHAR(255) NOT NULL, body CLOB NOT NULL, publicationDate DATETIME NOT NULL, PRIMARY KEY(id));
  CREATE INDEX...

Fixtures are fake data that allow testing of an app without having to do the tedious task of manually creating data after each install. They are useful for automated testing processes and make it easier for a new developer to start working on our projects.

Doctrine has an extension called Data Fixtures that ease fixtures creation. We will install it and use it to create some fake blog posts.

Type this command in the root of the project to install Doctrine Data Fixtures through Composer:

  php composer.phar require doctrine/data-fixtures:1.0.*

The first step to using Doctrine Data Fixtures is to create a fixture class. Create a file called LoadPostData.php in the src/Blog/DataFixtures directory as shown in the following code:

  <?php

  namespace Blog\DataFixtures;

  use...

We will create a simple UI to deal with our posts. This interface will let us create, retrieve, update, and delete a blog post. You may have already guessed that we will use the Entity Manager to do that.

For concision and to focus on the Doctrine part, this UI will have many drawbacks. It should not be used in any kind of production or public server. The primary concerns are as follows:

And of course this will be… graphically minimalistic!

We now have a minimal but working blog app! Thanks to Doctrine, persisting, retrieving, and removing data to a database has never been so easy.

We have learned how to use annotations to map entity classes to database tables and rows, we generated a database schema without typing a line of SQL, we created fixtures and we used the Entity Manager to synchronize data with the database.

In the next chapter, we will learn how to map and manage One-To-One, One-To-Many/Many-To-One, and Many-To-Many associations between entities.