Matthias Noback has a post to his site today covering the use of Doctrine with domain-driven design as it relates to the definition and creation of the entities in your system.

As I discovered recently, you don't need an edge case to drop Doctrine ORM altogether. But since there are lots of projects using Doctrine ORM, with developers working on them who would like to apply DDD patterns to it, I realized there is probably an audience for a few practical suggestions on storing aggregates (entities and value objects) with Doctrine ORM.

He starts the article off by making a recommendation when building out your domain and entities: don't build with the ORM in mind. Its easy to think that entities and ORM models are the same thing, but he recommends defining them first and then figuring out how to work them in to the model structure. Eventually storing them and their state will have to be considered but that shouldn't influence the design. He illustrates with simple Line and PurchaseOrder entities and how to modify the base classes so they can be managed by Doctrine. He also covers some of the other concerns of making the transition over from entities to models in Doctrine (constraints, custom DBAL types, etc). He finishes the post covering annotations, the "one transaction only" DDD idea and value objects.

On his Medium site Dragos Holban has a new tutorial posted as a part of his "Learn Symfony 2.8" series. This time he shows how to use Symfony OAuth authentication for a mobile application.

Let’s say you built an API using Symfony and you need to access it from a mobile application using authenticated requests on behalf of your users.

Here’s how to make this work using Symfony 2.8 and Doctrine.

He starts by helping you install the FOSOAuthServerBundle and how to enable it in your Symfony application's configuration. He then includes the code for the OAuth classes: the client and entities for the access token and access token handler. He shows how to configure the bundle and add in routing and configure security protection for the parts of your application. Next he shows the creation of a client and how to document your API using the NelmioApiDocBundle.

In this post to his site Martin Hujer suggests that you don't use entities directly in your Symfony forms, opting instead for custom functionality to persist form data.

Let's start with stating that using entities for validation in Symfony Forms is widely used and widely recommend approach. Even the official documentation suggests it.

And I don't think it is a good idea! Why? [Three reasons:] an entity should be always valid, change [in the future and] layers separation.

For each of these downfalls he gets into a bit of detail about what the issue is and introduces the alternative: a custom data class. This class is then used to represent the data in the form with some simple assertions. He includes an example of this kind of class with three properties: title, content and public date. He then shows how to build a form using this class and how to handle updates, not just creates, with the same functionality.

The SitePoint PHP blog has posted another in its series looking at Drupal 8 functionality today. In this latest post author Daniel Sipos looks at entity validation and typed data and what functionality the project provides over what was offered in previous versions (built on top of the Symfony validation component).

Data validation is a very important part of any application. Drupal 7 has a great Form API that can handle complex validation of submitted data, which can then be turned into entities. However, form level validation is problematic. [...] With the introduction of subsystems such as the REST API, Drupal 8 needed something better to handle this problem. [...] In this article, and its followup, we will explore the Drupal 8 Entity Validation API, see how it works, and how it can be extended.

He starts by looking at typed data and the consistency it provides in working with the metadata on objects. He includes a few examples of defining a string data type with a maximum length. He then applies this to content entities and enforcing the constraints provided by the types. In the next part of this series he'll look at the validation itself and how it works with these types/constraints.

The SitePoint PHP blog has an article posted by Vitalij Mik showing you how to merge the concepts of "clean code architecture" and test-driven development to make solid, maintainable code. The ideals of the "clean code architecture" were first proposed by Robert C. Martin in this post on the 8thlight blog.

The idea was to create an architecture which is independent of any external agency. Your business logic should not be coupled to a framework, a database, or to the web itself. [...] Frameworks will continue to change and evolve. With composer, it is easy to install and replace packages, but it is also easy to abandon a package (composer even has the option to mark a package as abandoned), so it is easy to make “the wrong choice”.

In this tutorial, I will show you how we can implement the Clean Code Architecture in PHP, in order to be in control of our own logic, without being dependent on external providers, but while still using them. We will create a simple guestbook application.

He starts with a first test, evaluating that a list of entries for the guestbook is empty. The code shows the "fakes" for the different object types Uncle Bob recommended in his article and how it fails because none of them exist yet. He extends this with a "can see entries" test and then starts in on the "use case" class to start making the test pass. He updates the case to pull in entries from the repository, another external dependency created later in the tutorial. He then goes through creating the classes for the "fakes" in the test and refactoring the test based on some of his changes during their development. In the remainder of the post he talks about the independence of the current setup and how to add in pagination functionality on the entries objects.

On the NetTuts site there's a tutorial posted helping you get familiar with Doctrine 2 (the ORM) and how to integrate it with a Laravel 5 application via a simple service provider.

As a PHP developer, you might have come across the term ORM. ORM is a way to work with databases in the same way you work with classes and objects. If you were to delve deeper into how web applications are designed and built, after doing some exploring in their ORM you would find two well-known patterns: Active Record and Data Mapper.

[...] With Data Mapper the in-memory objects needn’t know that there is even a database present. They need no SQL interface code or knowledge of the database schema. One such solution is Doctrine.

The tutorial walks you through some of the basic concepts in using the Doctrine 2 ORM including Entities and Repositories. Also included is how to pull it in via Composer and update your Laravel configuration to use this bridge library for integrating it into your current application. Code examples are included showing you how to build out an entity, repository and a validator class for a basic blog post.

On the SitePoint PHP blog there's a recent post showing you how to use traits with Doctrine entities. PHP's traits allow for the inclusion of functionality into a class without having to extend another class or create an object to use it.

Since PHP 5.4.0, PHP supports a pretty way to reuse code called “Traits” – a set of methods that you can include within another class in order not to repeat yourself. You can read more about traits in previously published SitePoint posts: here, here and here. Today, I am going to show you how they can be used with Doctrine ORM in a Symfony Environment.

He shows how to create two basic Doctrine entities, in this case representing "Article" and "Comment" instances. He then creates the trait, a "TimestampableTrait" class that abstracts out the setting/updating of the create and updated date on the Doctrine record. He refactors the entities to use the trait and shows the results of the "schema create" command.

The SitePoint PHP blog has a new tutorial posted from author Daniel Sipos about form handling in Symfony2. More specifically, about creating them and handling the results from their submission. This is an introduction to the topic and gets into two examples, one focusing on a view implementation and the other using the form builder.

In this tutorial we will look at two examples of using forms in Symfony 2. In the the first, we will place form elements straight in the View file and then handle the form processing manually in the controller. In the second, we’ll use the Symfony form system to declare forms in an object oriented way and have Symfony process and persist the values. We will be working on a simple installation of the Symfony framework.As you may know, it comes with a default bundle called AcmeDemoBundle and we will use that to illustrate working with forms.

In the first example he looks at "non-entity forms" and shows how to create the form from normal HTML elements in the view. The form is just a simple input field and a submit button. He includes the code you'll need to process the form submission too. In the second example he includes an example of how to create the same setup but using the Form Builder instead. It's also links it to a data object, making it simpler to save the submission results.

Matthias Noback has made a recommendation in his latest post about using a repository rather than an entity manager in your classes to inject dependencies.

It appears that I didn't make myself clear while writing about entity managers and manager registries yesterday. People were quick to reply that instead you should inject entity repositories. However, I wasn't talking about entity repositories here. I was talking about classes that get an EntityManager injected because they want to call persist() or flush(). The point of my previous post was that in those cases you should inject the manager registry, because you don't know beforehand which entity manager manages the entities you are trying to persist. By injecting a manager registry you also make your code useful in contexts where another Doctrine persistence library is used.

He suggests that more classes actually need a repository and not an entity manager to work with necessary objects. He also points out how the use of an entity manager can sometimes violate the Law of Demeter. He includes some code showing a refactoring away from an entity manager and towards a repository. He also has an example of a custom repository class based on the domain logic object types. In addition he talks about repository interfaces, resetting closed entity managers and "criteria" objects.

Ross Tuck has submitted a new article he's posted about persisting value objects in the popular PHP database storage and object mapping library, Doctrine. Value objects are immutable objects that " follow value semantics rather than reference semantics".

I’ve been using more and more Value Objects in my applications over the last year, primarily with Doctrine ORM. Value Objects are an extremely powerful technique and I’ve been impressed with how much they can clean up a codebase. One of the main questions I’ve had when starting with Value Objects is how to persist them with Doctrine. This post attempts to create a reference for all the different persistence techniques I’ve seen so far.

You'll need to be familiar with Value Objects and Doctrine before starting (it's not an "intro to Doctrine" article). His example sets up an "IPRange" and an "IPAddress" that are stored in a "Server" instance. He talks about mapping the value object to the database and the getter/setter to do the work. He also touches on DBAL types, working with multiple columns in the entity and the "promised land" of embeddables. He finishes off the post looking at collections of entities and some of the other options to what he's shown (including serialization).