Rob Allen has posted a tutorial to his site making some updates to his previous work with the Doctrine migrations handling as a standalone component. In this new tutorial he talks about the newer way to use it in your projects.

Since, I last wrote about using the Doctrine project's Migrations tool independently of Doctrine's ORM, it's now stable and much easier to get going with.

He starts with the basic installation and configuration of the migrations tool, making use of a SQLite database as an example. He then shows the use of the basics of using it to make database changes:

creating a new migration

running the migrations

Each step comes with code, the commands you'll need to execute and an example of the resulting console output.

On the SitePoint PHP blog there's a tutorial posted from Francesco Malaesta about the Laravel Doctrine project, wondering if it's the best of both worlds for connecting to databases and working with entities in your Laravel-based project.

He starts with a comparison of the two options - Doctrine vs Eloquent - and why you might choose the former over the latter. He then gets into the installation of a new Laravel project and pulling in the laravel-doctrine/orm package. He then shows it in action with a simple to-do list application, creating an entity for the tasks. From there he shows the use of the EntityManager to add a new task and find ones matching certain criteria. He makes a TaskController to handle the route functionality and creates the matching frontend views to allow the user to define new tasks. Also included is the code for the other "CRUD" (create, read, update, delete) handling for the tasks and the addition of the relationship between users and tasks.

The repository pattern was introduced for the first time by Eric Evans in his Domain-Driven Design book. The repository is, in fact, the entry point for the application to access the domain layer.

To put it simply, the repository allows all your code to use objects without having to know how the objects are persisted. The repository contains all the knowledge of persistence, including mapping from tables to objects. This provides a more object-oriented view of the persistence layer and makes the mapping code more encapsulated.

In this article they replace the default storage/persistence method for database records away from the default Eloquent over to Doctrine, a widely used ORM tool. The start with a brief comparison between Eloquent and Doctrine before starting on on a simple "blog" application. They connect Doctrine to Laravel via an "entity manager" and make a basic Doctrine-based model for the Posts and a matching repository/controller implementation. All the code you'll need to implement it is included along with a simple view to take in the post content and display errors if there were any on the save.

As a PHP developer, you may use the Test-Driven Development (TDD) technique to develop your software by writing tests. Typically, TDD will divide each task of the development into individual units. A test is then written to ensure that the unit behaves as expected. [...] TDD verifies that the code does what you expect it to do. If something goes wrong, there are only a few lines of code to recheck. Mistakes are easy to find and fix. In TDD, the test focuses on the behavior, not the implementation. TDD provides proven code that has been tested, designed, and coded.

[...] PHPUnit is the de-facto standard for unit testing PHP. It’s essentially a framework for writing tests and providing the tools that you will need to run tests and analyze the results. PHPUnit derives its structure and functionality from Kent Beck’s SUnit.

He briefly talks about some of the assertions that PHPUnit has to offer before getting into the support that Laravel includes and how to configure it so Doctrine can work with your database. He then talks about Doctrine, briefly introducing the popular database abstraction tool and how to integrate it with a Laravel application. From there he starts in on the tests themselves, showing code that uses fixture data to create several tests for Post and Comment data.

The BitExpert blog has a post sharing some of author Stephan Hochdörfer's experience in combining Doctrine and the ramsey/uuid-doctrine and willdurand/hateoas packages to create a system that follows the HATEOAS API documentation structure for his Doctrine-based objects.

Recently I experimented a bit with Doctrine ORM and the willdurand/Hateoas library to expose my Doctrine objects via an HATEOAS api which luckily is a fairly trivial thing to do. All you need to do is set up the Hateoas serializer and call the respective serialize() method passing your Doctrine object as well the serialization type.

He shares the code to make the integration work, pointing out that the ramsey/uuid-doctrine library makes masking the autoincrement database identifiers (their "id" column) with UUIDs easier. He shows how to integrate this Uuid data type into the Doctrine docblock configuration and how to use the HateoasBuilder to handle the serializer instance containing the Doctrine object/results.

Doctrine is currently the most used ORM in PHP. It makes it very easy to work with databases in an object oriented way. It comes with a set of built-in column types that map database types with PHP types. For example, the datetime column type, persists the value of an entity column as a datetime in the database and handles it as a DateTime object when the entity is hydrated.

Type conversions work both ways, so column types take care of casting database to PHP types and vice versa. In this article I'm going to explain how to define custom column types so that we can persist our own objects into the database and hydrate them back.

He points out that, while PHP itself lacks the "enum" data type, you can simulate it with a library like this. He uses this library to create a custom Doctrine object type that mimic enums in the getting and setting of a value to one of a few options. In this case it's values representing the CRUD methods. He shows the code to link the Type back to the Action which then gives it understanding of what the valid enum values can be. He also points out another package that he published recently that takes some of the work out of creating the boilerplate code for the enum.

On the /r/php subreddit on Reddit.com, TheSkilletHead wonders if ORMs are inherently limiting in PHP development. Their main point is that, in abstracting and simplifying the interface the developer has to work with, some of the power of the complex database handling is lost.

I don't feel like I'm asking too much from an ORM. I'm not asking for the ORM to manage database-side functions. I'm not asking it to manage database-side variables. I'm not asking it support every type of INSERT (like INSERT DELAYED). I'm OK that it doesn't support LOAD DATA INFILE. I'm even OK with the overhead. However, when I look up why Doctrine doesn't support UPDATE ... JOIN and the response is "it's too different across database engines", then I'm a bit disappointed because that seems to be why one would use an ORM in the first place. [...] Can an ORM be a useful tool to abstract the database or is it just a crutch for people who can't be bothered to learn SQL?

There's quite a few comments on the post already, most confirming his opinion that ORMs are limiting. Some, however, note that they don't have to be. There are some (like the CakePHP 3 ORM) that do have some more advanced features and are still easy to use. Despite this, most of the comments are about developers moving away from ORM use towards more specific, customized solutions that are a better fit for their needs and database systems.

Jonathan Wage has a new tutorial on his site showing you how to use the Symfony Expression Language to create simple logic statements. He illustrates with a project they (OpenSky) applied it on - a "reward" rules engine.

We recently adopted the Symfony Expression Language in the rules engine at OpenSky. It has brought a new level of flexibility to our system and creating new logic has never been easier. [...] The expression language allows you to perform expressions that get evaluated with raw PHP code and return a single value. It can be any type of value and is not limited to boolean values.

He starts with a simple example, showing how it can return a boolean based on the results of an evaluation of an array of data. He then takes this up to the next level and use it with a Doctrine object, evaluating the results of methods to apply "rewards" to a user's account. He shows how to define the Doctrine objects with the necessary methods, how to write the rule and a lookup class to find rules that apply to the current situation.

The ByMyCTO.com blog has a recent post that makes the suggestion that the Doctrine ORM isn't suited for PHP...or to put it another way why they think it's not a good option for database integration.

I know, this title sounds like a troll. But it’s not, it’s a fact. I’m not saying Doctrine is a bad technology or shouldn’t be used. I’m just saying it’s not suited for PHP and this can lead to critical problems if misused.

He covers a few different topics including:

Differences between Java and PHP (and the fact that Doctrine's inspiration was Hibernate)

The "session problem" (entity serialization)

Identity Map, useless in a stateless environment

UnitOfWork, far too complex

EntityManager, too magical

Despite all of these points, he does remind the reader that Doctrine isn't useless or inherently bad, it's just that he sees it as reinforcing bad behaviors and suggests using something else.

Bernhard Schussek has written up a new post to the Web Mozarts blog talking about resource discovery with Puli. Puli is a management tool for the non-PHP files in your applications (CSS, Javascript, YAML, etc). In this post he talks about the use of the discovery component and its use of resource binding.

Many libraries support configuration code, translations, HTML themes or other content in files of a specific format. The Doctrine ORM, for example, is able to load entity mappings from special XML files. When setting up Doctrine, we need to pass the location of the *.dcm.xml file to Doctrine’s XmlDriver. That’s easy as long as we do it ourselves, but what if someone else uses our package? How will they find our file? What if multiple packages provide *.dcm.xml files? How do we find all these files? We need to remove the appropriate setup code after removing a package [and] we need to adapt the setup code after installing a new package. Multiply this effort for every other library that uses user-provided files and you end up with a lot of configuration effort. Let’s see how Puli helps us to fix this.

He talks about the concept of package roles in the tool, breaking them down in resources and providers. He then shows how Puli makes it possible to discover resources by defining a type via Puli and the code for the discovery process. He then binds the XML configuration definition and executes a "find" to ensure it's configured correctly. Finally, he shows the process to use Puli in this Doctrine example allowing it to locate and use the XML mappings dynamically via a custom driver.