News Feed
Jobs Feed
Sections




News Archive
feed this:

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

Ross Tuck:
Persisting Value Objects in Doctrine
March 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).

0 comments voice your opinion now!
doctrine valueobject value object database entity dbal embeddables

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

Kristopher Wilson:
Decoupling the Framework
December 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.

0 comments voice your opinion now!
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?
October 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.

0 comments voice your opinion now!
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
October 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.

0 comments voice your opinion now!
symfony2 repository injection configuration tutorial entity manager

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

Rob Allen:
Objects in the model layer Part 2
April 02, 2013 @ 11:55:50

Rob Allen previously 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.

0 comments voice your opinion now!
object model layer entity mapper service interface book


Rob Allen:
Objects in the model layer
March 22, 2013 @ 10:45:54

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.

0 comments voice your opinion now!
object model entity mapper service oop structure znedframework2


Michael Nitschinger:
Caching Doctrine Entities with Couchbase
January 08, 2013 @ 10:19:07

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.

0 comments voice your opinion now!
doctrine entity cache orm couchbase tutorial


Bradley Holt:
Entity Relationships in a Document Database at ZendCon 2012 (Video & Slides)
November 19, 2012 @ 10:03:55

If you weren't able to attend this year's ZendCon conference and wanted to see Bradley Holt's talk about entity relationships and document databases, you're in luck - he's posted both the video and slides to his site. Here's his summary of the session:

Unlike relational databases, document databases like CouchDB and MongoDB do not directly support entity relationships. This talk will explore patterns of modeling one-to-many and many-to-many entity relationships in a document database. These patterns include using an embedded JSON array, relating documents using identifiers, using a list of keys, and using relationship documents. This talk will explore how these entity relationship patterns equate to how entities are joined in a relational database. We'll take a look at the relevant differences between document databases and relational databases. For example, document databases do not have tables, each document can have its own schema, there is no built-in concept of relationships between documents, views/indexes are queried directly instead of being used to optimize more generalized queries, a column within a result set can contain a mix of logical data types, and there is typically no support for transactions across document boundaries.

He also includes links to two of the tools he mentions in the talk - Doctrine CouchDB and the Doctrine MongoDB ORM.

0 comments voice your opinion now!
zendcon12 entity relationships document database video slides


Evan Coury's Blog:
Using ZendDb's TableGateway & HydratingResultSet to return rows as custom enties
July 02, 2012 @ 09:32:55

Evan Coury has a new post to his blog about using ZendDb's TableGateway (from the Zend Framework 2) along with the HydratingResultSet feature to let you build objects from your database results.

The new ZendDb in Zend Framework 2 has a handy feature which allows you to specify your own entity/model class to represent rows in your database tables. This means you can tell ZendDb to return each row as a populated instance of your own custom objects. Keep in mind that this is simply a convenience feature, and not meant to serve as a fully-featured ORM. If you're looking for a full-blown ORM, have a look at Doctrine 2.

He includes some example SQL to create a "book" table and the ZF2 code to create the Book model, set up the database connection and generate the hydrated data set from the results. An example of doing an insert into the table and then pull it back out from the TableGateway object.

0 comments voice your opinion now!
tutorial zendframework2 tablegateway hydratingresultset entity model object


DevShed:
Service Layers in PHP Applications (a Series)
October 18, 2011 @ 08:50:09

DevShed has posted a series of tutorials talking about different sorts of service layers in PHP applications - seven of them to be exact:

If you're looking for an approachable guide that teaches you how to implement an easily-customizable service layer in PHP, then take a peek at this article series. In a step-by-step fashion, it walks you through the development of a sample web application, which uses a service to perform CRUD operations on a domain model composed of a few user entities.

Service layer types covered in the series are:

0 comments voice your opinion now!
series service layer entity datamapper domainobject dependency injection



Community Events











Don't see your event here?
Let us know!


podcast application overview hhvm security unittest package introduction symfony2 performance facebook opinion code framework hack composer component release language install

All content copyright, 2014 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework