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.

New on the Zend Developer Zone today is their latest episode in their PHP Abstract podcast series - an interview with Paul Tomlinson about Topor.

PHP Abstract has a new episode! This time I'm talking with Paul Tomlinson about Torpor, a new ORM persistence abstraction layer for PHP. He talks about the reasons behind making this new layer, and how it's features compare to other similar solutions.

As always you can listen in one of three ways - either via the in-page player, by downloaing the mp3 or by subscribing to their feed and getting this and other great episodes hand-delivered to your client.

In response to this older post Ralph Schindler has posted some of his own thoughts on database abstraction layers - they must live!

Interestingly, I can put the vocal proponents of each side of the argument in one of two boxes: a programmer guy box, or a database guy box. For some unknown reason though, they never seem to see eye to eye. [...] Generally speaking of database driven projects, I feel like planning to use a specific vendor up front, knowing its pro's and con's, and tailoring an application to the chosen database's strengths can only help in the long run. Also, I feel that building a database model first before any code, offers many performance and scalability advantages than does code first development.

He notes that, while he agrees on the problems with the "switching databases at any time" problems the other author brings up, he points out that the abstraction layers do have their place. He includes an example of an abstraction layer with the Zend_Db object of the Zend Framework. His sample code shows how it can be used to simplify your interaction with your database.

Jeremy Zawodny has shared his opinion on database abstraction layers in PHP applications - they need to die.

Beware of men preaching of false hope. Take, for example, the way some folks feel like they need a database abstraction layer in their applications. [...] So why do folks do it? Because PHP is also a programming language and they feel the need to "dumb it down" or insulate themselves (or others) from the "complexity" of PHP.

He goes on to say that, despite the claims that people make about portability ("it's never that easy") and ease of use, the only real answer is to strip out this layer and use good programming practices to take the database access code out into a separate library that can be replaced quickly and easily.

Leendert Brouwer has come up with a (complete) look at PHP backends as written for Zend Framework applications.

Some of these frameworks became rather popular, but the big hit in PHP's framework department came when Zend released its own framework - the Zend Framework. Being "the PHP company" and all, their framework got a lot of attention. And it wasn't all marketing buzz. It really is a fairly well architected, functional piece of software that can make the lives of developers easier. But what did the Zend Framework offer us, in reality?

He looks at some of what the framework has to offer - public interfaces, simplified database refactoring, parallel development - and domain objects. The bulk of the post deals with the Service Layer - how to more correctly split out controller functionality from model functionality and separate our the layers accordingly. He throws in a few opinions near the end about things like upfront design, application scale and the possible overhead of his approach.

DevShed continues their series on the Active Record pattern in PHP with this new article implementing the LIMIT statement on your abstraction class.

In its current version, it'll be able to accomplish only a few basic database operations tasks. Therefore, this fifth article of the series will be focused on enabling the class to fetch database rows by using the LIMIT clause.

They add the LIMIT clause as a part of its own function and its own SQL statement. You define the number of rows to fetch, the table to fetch it from and the offset to start from. The SQL is passed off to their fetchRow statement and the results are returned in an array.

DevShed continues their look at the Active Record pattern with this third part of the series focusing on a new method in their class that will make select requests for the Active Record layer.

If you're a PHP programmer who wants to learn how to implement the active record pattern within a MySQL abstraction class to make your database-driven applications more robust and maintainable, then look no further. [...] In this third chapter of the series I'm going to show you how to add a new method to the class. It will be charged with executing conditional SELECT statements via a modified version of the active record pattern.

After reviewing the CRUD functionality from the previous articles, they add in the new method - a fetchWhere function that allows the user to submit a table name and the parameters to add to the where clause as an array. Some sample code is included.