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:

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

In this new post to his blog, Gonzalo Ayuso compares two technologies that can make working with databases in your applications simpler - PDO and the Doctrine2 DBAL layer.

In fact DBAL isn't a pure database abstraction layer. It's built over PDO. It's a set of PHP classes we can use that gives us features not available with 'pure' PDO. If we use Doctrine2 we're using DBAL behind the scene, but we don't need to use Doctrine2 to use DBAL. We can use DBAL as a database abstraction layer without any ORM. Obiously this extra PHP layer over our PDO extension needs to pay a fee. I will have a look to this fee in this post.

He includes a few simple benchmarking scripts that compare similar operations done by either, including memory usage and execution time. PDO comes out on top, obviously, because it's an extension versus a set of PHP libraries that need to be included in the application. He does include examples of a few things he likes that DBAL does that PDO doesn't by default - a transactional mode, type conversion, a simpler binding interface and the ability to nest transactions.

Jani Hartikainen has a new post to his blog today about why, in your framework-based applications, it's okay to have "fat controllers" instead of a service layer.

Here's a counterpoint to the currently popular view of "fat controllers are bad", and the current fad of everyone and their cousin implementing service layers: You don't need one. Fat controllers are okay too.

He starts by explaining the "why you don't need a service layer" part, mentioning that keeping it in the controller keeps things simple and keeps your code from having to go through extra hoops just to work correctly. He also points out that, just because he recommends "fat controllers" doesn't mean he's advocating code reuse. In fact, just the opposite:

It's fine if you code your things in the controllers, but there comes a point when you should stop that. The moment you realize you're duplicating your code, stop and refactor. This is one of the very basics of software engineering: Avoid duplication by creating functions and classes.

On the Zend Developer Zone today there's the first part of a series from Vic Cherubini about an ORM tool he's created to make pulling data from your database of choice (via PDO objects) simpler - DataModler. This first part looks at creating testable models.

DataModeler allows you to create easily testable Models that are not dependent on any datasource. The majority of your logic should take place in the Model, and not the Controller (making your application even easier to test as data sources can be mocked). I try to keep my code as simple as possible, so DataModeler is fairly small.

He talks about how the DataModler tool uses dependency injection and how one primary namespace (DataModlerModel) contains the bulk of the code. He includes code samples showing how to create a simple mode, give the attributes data types and access them via magic "set" and "get" methods. For more information on this ORM tool, check out the latest source on github.

On the php|architect blog today Bill Karwin looks at a new library - Crystal - a database library to help make it simpler to work with SQL (and make it more human-readable).

Martin [Rusev]'s project is called Crystal. It's an object-oriented wrapper for the venerable mysql and pg extensions, with the goals of making SQL more human-readable, and providing a library that is lightweight and easy to learn.

There's code examples on the site of how to use the library. Bill also mentions some of the things the project does well and a few things it doesn't - like leaving out some of the advanced SQL functionality in favor of simplicity. He also mentions concerns about SQL injection handling, code not shared between database handlers and the unfinished nature of some features.

According to this latest tutorial from NETTUTS.com, you should be using PHP's PDO database access layer to interact with your database of choice.

Many PHP programmers learned how to access databases by using either the mysql or mysqli extensions. Since PHP 5.1, there's been a better way. PHP Data Objects (PDO) provide methods for prepared statements and working with objects that will make you far more productive!

The introduce what PDO is, what kind of databases it supports and, of course, some code to get you started in connecting your application to the backend. They show how to handle exceptions, how to use placeholders, and performing inserts and selects on your data.

In a new post on the Rdavid.net blog there's some discussion about Zend Framework models, the best approach and a "Service Class" idea.

After some more thought and lots of research on the subject, I've come to a solid point where I actually have something to try out which seems semantic aside from the naming of the class (Service Class) '" but this is derived from what some people are talking about in ZF circles starting from Matthew Weier O'Phinney who was coining it as the "Gateway to the Domain" from early on, then later changing it to "Service Class".

He defines what his service class idea is - a layer between the database and each of the models that allows them to be agnostic about what kind of service they're using. He also breaks down some of the key points around his approach including the fact that the Model Service can create Forms and that the Model Service can use the Zend_Cache component directly for improving performance. Be sure to check out the comments for thought from other Zend Framework developers.

In a recent post to the NETTUTS.com site Juan Mellado looks at creating caching that will fit in with your a data access layer in your application.

Dynamic web pages are great; you can adapt the resulting page to your user, show other user's activity, offer different products to your customers based on their navigation history, and so on. [...] In this tutorial, I will demonstrate a way to improve performance, without running extra unnecessary queries. We'll develop a query caching system for our data layer with small programming and deployment cost.

He breaks it up into a few different sections:

• The Data Access Layer
• Planning our Caching Scheme
• Static Caching
• Caching Expiration
• Different Expiration
• Some Caveats
• A Benchmark

That benchmark section there at the end mentions that, while caching can help increase page load times, it's not a silver bullet to solve the problem of bad code. Their solution, however, increased the average request time from about four pages per second up to around twenty-five pages per second.

In a new post to his blog Juozas Kaziukenas takes a look at one of the pieces of "glue" that makes up the typical web application - the service layer.

During this year I invested quite a lot for a search of a good ways to architecture a big application and make it simply good. Quite a while ago Matthew Weier O'Phinney introduced service layer in one of his great talks about models, since then service layer become one of the key architectural component one my applications. Here I'm going to show a few examples and use cases where it's very useful.

He looks at the "old style" of data interaction that several applications use as compared to injected objects and information more structured applications have put to use. He also outlines a practical use of the service layer structure - thinking of it as a layer allowing to you connect to a service, either local or remote, without the rest of the application needing to know about it.

In his latest blog post Federico Cargnelutti talks about data access layers, data access objects, data mappers and how to implement them in a Zend Framework application.

In his example code he creates a few new directories in his basic application layout under the "lib" directory to contain the files for the mapper, data access layer and data objects. He uses s simple "user" table with first and last names and an ID to help identify the row.

The User model, mapper and data access object work together to make a simple "getUser" method as easy as creating a new Project_DataMapper_User object and setting up the entity before doing the fetch with a "get" call.