PHPDeveloper.orghttp://www.phpdeveloper.org
Up-to-the Minute PHP News, views and communityen-usTue, 03 Mar 2015 13:01:50 -060030http://www.phpdeveloper.org/news/22079http://www.phpdeveloper.org/news/22079
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.

Link: http://www.sitepoint.com/using-traits-doctrine-entities/]]>Tue, 09 Dec 2014 12:16:56 -0600http://www.phpdeveloper.org/news/21273http://www.phpdeveloper.org/news/21273
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.

Link: http://www.sitepoint.com/building-processing-forms-in-symfony-2]]>Fri, 06 Jun 2014 13:45:07 -0500http://www.phpdeveloper.org/news/21189http://www.phpdeveloper.org/news/21189
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.

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

Link: http://rosstuck.com/persisting-value-objects-in-doctrine/]]>Mon, 03 Mar 2014 10:11:29 -0600http://www.phpdeveloper.org/news/20462http://www.phpdeveloper.org/news/20462
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.

Link: http://kristopherwilson.com/2013/11/27/decoupling-the-framework/]]>Mon, 02 Dec 2013 12:19:36 -0600http://www.phpdeveloper.org/news/20287http://www.phpdeveloper.org/news/20287
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.

Link: http://programmingarehard.com/2013/10/21/is-orm-abstraction-a-pipe-dream.html]]>Wed, 23 Oct 2013 09:59:21 -0500http://www.phpdeveloper.org/news/20266http://www.phpdeveloper.org/news/20266
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.

Link: http://blog.sznapka.pl/injecting-repositories-to-service-in-symfony2/]]>Thu, 17 Oct 2013 11:45:54 -0500http://www.phpdeveloper.org/news/19398http://www.phpdeveloper.org/news/19398
Rob Allenpreviously posted about some of his practices around the different types of objects in the model layer of his Zend Framework 2 applications. In this latest post he follows up and shares some example code for the different types.

I previously talked about the terms I use for objects in the model layer and now it's time to put some code on those bones. Note that,as always, all code here is example code and not production-ready.

He includes sample classes related to his "books" examples - a "book" entity (with title, author, id and ISBN), a mapper object to load/save/delete the entity and a service object that provides an interface for the entity to the rest of the application.

]]>Tue, 02 Apr 2013 11:55:50 -0500http://www.phpdeveloper.org/news/19350http://www.phpdeveloper.org/news/19350
In this latest post to his site Rob Allen talks some about application structure and the different kinds of objects he uses in his applications.

I currently use a very simple set of core objects within my model layer: entities, mappers and service objects. [...] I dislike the phrase "service object" as the word "service" means so many things to so many people. I haven't heard a better phrase yet that everyone understands though.

He defines each of the types of objects to help make the separation clearer. Here they are in brief:

Entities are objects that represent something in my business logic.

Mappers know how to save and load an entity from the data store.

Service objects provide the API that the rest of the application uses.

Some of the comments on the post relate his choices to use in Zend Framework v2-based applications, noting that there are some base components you can extend to create these kinds of objects.

]]>Fri, 22 Mar 2013 10:45:54 -0500http://www.phpdeveloper.org/news/19006http://www.phpdeveloper.org/news/19006
Michael Nitschinger has a new post to his site today showing how you can cache the entities you've created with Doctrine using Couchbase as a simple caching tool.

As part of our ongoing efforts to make Couchbase more integrated with frameworks and libraries, we added caching support for the Doctrine ORM. [...] Caching can either be used standalone (through the API provided by doctrine/common) or integrated with the ORM functionality. We'll look at both variants through simple examples, a good documentation can also be found here. Note that at the time of writing, the CouchbaseCache is not mentioned as a caching driver because the documentation still needs to be updated.

He walks you through the steps to get everything you need installed, both through Composer and the Couchbase extension so your PHP installation will support it. He includes sample code that sets up the cache and shows how to check it to see if a key exists. With this base in place, he expands it out to working with the Doctrine ORM. He shows how to create a sample "Person" entity, inject it into the entity manager and perform a query with the Result Cache to locate the object.