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.

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.

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.

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.

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.

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:

• Working with database entities
• Data Mappers
• Database adapters
• Handling Entity Collections
• User Services
• Dependency Injections
• Modeling Domain Objects

Since the start of the Doctrine MongoDB Object Document Mapper project people have asked how it can be integrated with the ORM. This blog post demonstrates how you can integrate the two transparently, maintaining a clean domain model. This example will have a Product that is stored in MongoDB and the Order stored in a MySQL database.

His code shows how to define the document and entity for the connection (a Product and Order) and creating an event subscriber to lazy load the product. He creates a sample Product and an Order for it and save them to the database. He also includes code to pull an order back out by its ID number and get an Order object back out (with Product data inside).

In the last post, I introduced Dependency Injection and show useful cases where it allows classes decouplng. I also wrote about the problem of how to inject a service in a class that has to be instantiated not application wide but in the business logic.

He creates an example that shows a not-so-good place to use dependency injection and offers a solution - a factory that creates the objects as they're needed instead of having them floating around when they're not needed. He also talks about the difference between two types of business objects to consider in dependency injection: entities and services (hint: one depends on the other).

The standard htmlentities() function will encode special characters so that they display OK in the browser. However, sometimes you might want to encode different languages to entities too. I just found a script that will do that in the form of an html encode application.

He includes an example showing how to encode a string of non-english characters out to an easy-to-display HTMLified string.

Coming in at number one by an overwhelming lead was "Not escaping entities and SQL input" (a definite problem indeed) with the next highest option, "Not using a Framework" a full twenty percent lower. The next two options were closer (descending) - "Using old PHP versions" and "No or little use of Object Orientation".

There's a new poll this week for your consideration - this time asking which stage, of the five options, should come first in the development cycle of a typical content management system. Head on over and cast your vote today!