Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

SitePoint PHP Blog:
Drupal 8 Entity Validation and Typed Data Explained
Mar 30, 2016 @ 12:18:28

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.

tagged: drupal8 validation entity typed data tutorial introduction

Link: http://www.sitepoint.com/drupal-8-entity-validation-and-typed-data-explained/

SitePoint PHP Blog:
Clean Code Architecture and Test Driven Development in PHP
Feb 09, 2016 @ 09:13:28

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.

tagged: cleancode architecture testdriven development tdd tutorial entity repository decouple

Link: http://www.sitepoint.com/clean-code-architecture-and-test-driven-development-in-php/

NetTuts:
Doctrine ORM and Laravel 5
Nov 19, 2015 @ 10:55:39

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.

tagged: introduction integration tutorial laravel orm doctrine2 entity repository validator

Link: http://code.tutsplus.com/tutorials/doctrine-orm-and-laravel-5--cms-24914

SitePoint PHP Blog:
Using Traits in Doctrine Entities
Dec 09, 2014 @ 12:16:56

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.

tagged: traits doctrine entity tutorial introduction functionality

Link: http://www.sitepoint.com/using-traits-doctrine-entities/

SitePoint PHP Blog:
Building and Processing Forms in Symfony 2
Jun 06, 2014 @ 13:45:07

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.

tagged: symfony2 form processing view builder entity manager tutorial

Link: http://www.sitepoint.com/building-processing-forms-in-symfony-2

Matthias Noback:
Inject a repository instead of an entity manager
May 19, 2014 @ 11:04:30

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.

tagged: repository entity manager doctrine refactor example

Link: http://php-and-symfony.matthiasnoback.nl/2014/05/inject-a-repository-instead-of-an-entity-manager/

Ross Tuck:
Persisting Value Objects in Doctrine
Mar 03, 2014 @ 10:11:29

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).

tagged: doctrine valueobject value object database entity dbal embeddables

Link: http://rosstuck.com/persisting-value-objects-in-doctrine/

Kristopher Wilson:
Decoupling the Framework
Dec 02, 2013 @ 12:19:36

Kristopher Wilson has a new post to his site talking about something that could be very difficult with an existing application (and a good starting place for a new one) - decoupling from the framework. He advocates that your application shouldn't be an extension of the framework, more so a user of it to make it potentially easy to replace.

We spend a lot of time discussing and analyzing the features and merits of several frameworks, trying very hard to make sure we find the perfect one to use for our project. Rightfully so: picking the wrong framework can lead to a slew of issues down the road in terms of maintenance and scalability. [...] We also spent a considerable amount of effort making sure that there is minimal amount of coupling within our code. Strong coupling leads to problems testing, adapting, refactoring and reusing code. What if we applied that same principal to dealing with whatever framework we're using?

He goes on to look at the "framework is not your application" concept and fleshes it out with examples of it applied to a few different topics: Controllers, Models and ORMs. He also shows how, through the use of something like Doctrine's EntityManager, you can easily abstract things out so the internals of the application can easily split the application and framework.

tagged: decouple framework controller model orm doctrine entity

Link: http://kristopherwilson.com/2013/11/27/decoupling-the-framework/

David Adams:
Is ORM abstraction a pipe dream?
Oct 23, 2013 @ 09:59:21

David Adams has published a recent post that wonders if ORM abstraction is a "pipe dream" when it comes to abstraction. ORM stands for "object relational mapper" and is commonly used as a layer between the application and a dta source to work with the data as objects, not directly with it. He instead investigates replacing the ORM layer with multiple instances of repository pattern-structured code to abstract thing even more.

I was recently introduced to the repository pattern, a type of abstraction and organizational technique. The idea being, create a repository for each of your models to retrieve and persist to and from. A supposed benefit of the repository pattern is the ability to abstract your ORM and create different implementations for Eloquent, Doctrine, Propel, etc. This abstraction intrigued me. I set off to put this idea into practice and see what it took. Here are my findings.

He looks into how Doctrine handles its entities and tries to mimic some of the logic, including the calls to "save" and "flush". He also looks at how to handle a few other common ORM-ish topics like relationships, validation and observers. Unfortunately, he hit a wall with his solution and wasn't able to figure out a good Repository-based solution.

tagged: repository designpattern proofofconcept orm object mapper doctrine entity

Link: http://programmingarehard.com/2013/10/21/is-orm-abstraction-a-pipe-dream.html

Wojciech Sznapka:
Injecting repositories to service in Symfony2
Oct 17, 2013 @ 11:45:54

Wojciech Sznapka has an interesting new post to his site today talking about injecting repositories into services in Symfony2-based applications. By injecting just a single repository instead of the entire EntityManager, you get a cleaner, more clear interface defined in the code.

It is generally a good idea to wrap business logic into services. Often, such services methods uses doctrine’s repositories to operate on data storage. Injecting whole EntityManager service is very popular approach, but it isn’t the most elegant way I could think of. EntityManager works only as a factory in that case and could lead to usage of other repositories, which might end up with too many responsibilities of given service.

He includes some code to illustrate his point - both a "services.xml" configuration of the related dependency injection container and a custom entity repository (defined in the config). He then shows how this repository (FooRepository) would be injected into the service (FooService) via constructor injection.

tagged: symfony2 repository injection configuration tutorial entity manager

Link: http://blog.sznapka.pl/injecting-repositories-to-service-in-symfony2/