Service layers explained simply
Being new to MVC's is a bit confusing. There's a lot of acronyms to understand before you can really start jumping in and coding anything. This couldn't be any more true for ZF -- ZF not only gives you a framework full of buzzwords, it also leaves the interpretation of what each really means up to you.
As a disclaimer, I have to admit that I am no where near the genius of someone like Matthew Weier O'Phinney. If you are, you probably will get little to nothing out of this blog post. In that case, I recommend you read this slideshow on service layers, presented by the lead ZF developer and guru himself.
I read and re-read those slides many times -- but I'm the type of person who doesn't understand something until I've experienced it. I was running into a problem with my MVC apps where I was re-writing controller code for manipulating models quite often. Throw AJAX into the mix and suddenly I'm copying and pasting whole actions almost completely. Throw a public facing web service into the mix and I've tripled my code size. My my, not very pragmatic at all.
Implementing the service layer
So, what's a programmer to do? If you're following the paradigm that controllers are solely for accepting input and rendering output, which I do, then the problem you have -- that is, the code you're copy and pasting -- needs to be re-used instead of re-copied. This is where the service layer comes in for me. The service layer becomes a common API for all your controllers to use - whether through AJAX, Web service, or your plain old webpage controllers.
For example, I have a service I call Service_User. This service contains static methods for reading and writing user models. Example method skeletons look like this:
public static function save($user_id,$data) {
// Neat things happen here that saves a user model
}
public static function fetchAll($params) {
// Neat things happen here that returns a collection of user models
}
public static function delete($user_id) {
// Neat things happen here that deletes a user from the database
}
}
Now, all I have to worry about in my controllers is transforming the incoming data to correspond to the parameters of my service layer. My admin module, ajax module, and normal member controllers now all touch the very same code.
Why don't I just make my model methods more useful?
This was my gut reaction as well. Indeed, this is what I ended up doing on a whole application. You'll run into a couple of problems:
- These type of methods generally deal with input and output, while the goal of the model is usually to represent something logically in your application.
- You'll usually want methods that deal with collections of models, which doesn't organize well within a model.
I hope this helps clear up some confusion on service layers (well, at least how I use them). Think of them as the API for your application -- if you were going to externalize the internals of your application, what functions would you make? The service layer is the glue in between your models and controllers.
Over-engineering syndrome and becoming results-oriented
In January, I reflected on year 2009 as it pertained to my programming career. What had I accomplished?
I thought long and hard about this. I didn't publish any kick-ass new websites. I didn't make any major contributions to an open source project. The crowning achievement of my year was a Facebook app that accidentally exploded in popularity when it was really just meant to be a "Hello World!" app to learn the Facebook API.
But this made no sense -- I spent more time than I ever had in code over the past 365 days.
Somewhere along the way I lost sight of the goals. I did not become a programmer because I was amused with math, engineering, or manipulating computers. I became a programmer to create things that have a real impact on the world in some way, even if only slightly. When I first started programming, my code was hideous, insecure, and unmaintainable. But they worked. They had an input, and more importantly, they had an output. And that output did something useful. Why did the culmination of my last year of work have so little output?
The past year has been a great learning experience in other ways, of course. I learned Zend Framework inside and out. I built my own true MVC stack from scratch for learning purposes. I spent tons of time understanding different domain model implementations and formal ORM libraries. And now it's time to put that knowledge to use. I'm switching gears back to being a results-oriented developer.
This made me realize why developer managers push deadlines so hard. Ship your code. Perfect code is not perfect unless it's shipped.
Understanding design trade-offs and cutting features is a skill, not an option.
Part II: Managing CSS and JavaScript files within a Zend Framework App
Since my first post seemed to garner a good amount of attention I thought I'd follow up with another post on how to optimize our CSS/JS view helper components a bit.
The biggest suggestion -- and rightfully so, was to minify or gzip the extra controller/action Javascript or CSS file.
It doesn't take a lot of imagination to implement an improvement. There are several easy ways we can prevent the client (our users) from needing to download another CSS or JS file to view a particular controller action.
Firstly, we can get both the CSS and JS files to output in-line instead of loading as a separate file very easily:
File: /application/views/helpers/JavascriptHelper.php
class Zend_View_Helper_JavascriptHelper extends Zend_View_Helper_Abstract
{
function javascriptHelper() {
$request = Zend_Controller_Front::getInstance()->getRequest();
$file_uri = 'media/js/' . $request->getControllerName() . '/' . $request->getActionName() . '.js';
if (file_exists($file_uri)) {
$this->view->headScript()->appendScript('/' . $file_uri);
}
}
}
In the CSS helper, we'll use the HeadStyle helper instead of the HeadLink helper:
File: /application/views/helpers/CssHelper.php
class Zend_View_Helper_CssHelper extends Zend_View_Helper_Abstract
{
function cssHelper() {
$request = Zend_Controller_Front::getInstance()->getRequest();
$file_uri = 'media/css/' . $request->getControllerName() . '/' . $request->getActionName() . '.css';
if (file_exists($file_uri)) {
$this->view->headStyle()->appendStyle(file_get_contents($file_uri));
}
return $this->view->headStyle();
}
}
If you were using the previous version of the CSS helper, make sure you update your layout to echo the HeadStyle helper. Be aware that the file references (e.g., background images) in your controller / action CSS files will now have a new base URL, so you will need to update accordingly.
The next level - minifying the inline output
The next obvious step is to minify the additional output. My first inclination was to use the CSS/JS minify library aptly titled minify, however, that does a lot more than we need. I'm not a big fan of adding large libraries for the sake of one function, so let's instead explore how we can create exactly what we need within our view helper.
A little more googling gets us to this solution. Sure, it's not perfect, but performing 90% of the necessary packing is good for me.
My CSS view helper now turns into this:
File: /application/views/helpers/CssHelper.php
class Zend_View_Helper_CssHelper extends Zend_View_Helper_Abstract
{
function cssHelper() {
$request = Zend_Controller_Front::getInstance()->getRequest();
$file_uri = 'media/css/' . $request->getControllerName() . '/' . $request->getActionName() . '.css';
if (file_exists($file_uri)) {
$css = $this->minify(file_get_contents($file_uri));
$this->view->headStyle()->appendStyle($css);
}
return $this->view->headStyle();
}
function minify($css) {
// 90% minifying from http://www.lateralcode.com/css-minifer/
$css = preg_replace('#\s+#',' ',$css);
$css = preg_replace('#/\*.*?\*/#s','',$css);
$css = str_replace('; ',';',$css);
$css = str_replace(': ',':',$css);
$css = str_replace(' {','{',$css);
$css = str_replace('{ ','{',$css);
$css = str_replace(', ',',',$css);
$css = str_replace('} ','}',$css);
$css = str_replace(';}','}',$css);
return trim($css);
}
}
For the JS packer, we'll use Dean Edward's Javascript Packer that was ported to PHP by Nicolas Martin. You can download the class here:
Download Javascript Packer by Dean Edward
I added the JS packer to /library/jspacker/JavaScriptPacker.php. I modify my JavaScript helper by doing the following:
File: /application/views/helpers/JavascriptHelper.php
class Zend_View_Helper_JavascriptHelper extends Zend_View_Helper_Abstract
{
function javascriptHelper() {
$request = Zend_Controller_Front::getInstance()->getRequest();
$file_uri = 'media/js/' . $request->getControllerName() . '/' . $request->getActionName() . '.js';
if (file_exists($file_uri)) {
$javascript = file_get_contents($file_uri);
require_once('jspacker/JavaScriptPacker.php');
$packer = new JavaScriptPacker($javascript);
$this->view->headScript()->appendScript($packer->pack());
return $this->view->headScript();
}
}
}
The major disadvantage to this is debugging can be a pain when you don't have line numbers or variable names to reference. Thus, I added a conditional statement that only packs the Javascript if not in the development environment:
if (APPLICATION_ENV != 'development') {
$packer = new JavaScriptPacker($javascript);
$javascript = $packer->pack();
}
$this->view->headScript()->appendScript($javascript);
Presto! Auto-minifying, auto-packing inline Javascript and CSS only when we need it for our controller/actions.
Next steps? I suspect our next step is to add some server side caching so all this parsing doesn't happen in real time at the client's expense. Look for a short part 3 using Zend_Cache very soon.
Questions, comments? Please feel free to leave them below!
Managing CSS and JavaScript files within a Zend Framework App
When I'm creating a large external facing website or application, one of the biggest messes I used to end up making was in my CSS and JavaScript files.
As a developer/designer (jack of all trades, master of none, if you will) I tend to stay away from some of the more common developer solutions that take care of a lot of the design overhead (e.g., jQuery UI framework, Dojo, etc). Flexibility is paramount to good design -- boxing yourself into a specific layout for every page is bound to produce a boring, forgettable website. Design is highly underrated to developers, I believe a good aesthetic sense is a skill worth maturing for anyone who develops web applications. After all, you can have the most beautiful underlying code, but if it's presentation is anything short of beautiful it completely loses its "wow" factor.
Full design control usually means large, thousand plus line CSS files that equal serious pain when it comes to maintenance or building upon. If you don't namespace your selectors carefully you'll end up paying for it down the road. And heaven forbid you apply a default HTML tag styling. So, ranting aside, how do you maintain flexibility and still keep tidy CSS and JavaScript? My solution is to keep the very same directory/file structure that is used for the application for my CSS and JavaScript. The best part is by writing a very simple view helper, it's super easy to automate the proper head link and script file inclusions.
Here's what my CSS and JavaScript view helpers look like:
File: application/views/helpers/JavascriptHelper.php
class Zend_View_Helper_JavascriptHelper extends Zend_View_Helper_Abstract
{
function javascriptHelper() {
$request = Zend_Controller_Front::getInstance()->getRequest();
$file_uri = 'media/js/' . $request->getControllerName() . '/' . $request->getActionName() . '.js';
if (file_exists($file_uri)) {
$this->view->headScript()->appendFile('/' . $file_uri);
}
}
}
File: application/views/helpers/CssHelper.php
class Zend_View_Helper_CssHelper extends Zend_View_Helper_Abstract
{
function cssHelper() {
$request = Zend_Controller_Front::getInstance()->getRequest();
$file_uri = 'media/css/' . $request->getControllerName() . '/' . $request->getActionName() . '.css';
if (file_exists($file_uri)) {
$this->view->headLink()->appendStylesheet('/' . $file_uri);
}
return $this->view->headLink();
}
}
With that done, add the helper to your layout in the
section:File: application/layouts/scripts/layout.phtml
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>My app title</title>
<? $this->headLink()->appendStylesheet('/media/css/global.css') ?>
<? $this->headLink()->appendStylesheet('/media/css/iefix.css','screen','lt IE 7') ?>
<?= $this->cssHelper() ?>
<? $this->headScript()->appendFile('/media/js/jquery-1.3.2.min.js') ?>
<? $this->headScript()->appendFile('/media/js/global.js') ?>
<? $this->javascriptHelper() ?>
<?= $this->headScript() ?>
</head>
Now, anytime a controller action is invoked it will look for a javascript and css file in the same controller/action file path. In the above examples I've hard-coded the CSS and Javascript parent directories (/public/media for me) directly in to the code, but this would be pretty easy if you wanted to throw it in a config file or something instead. Otherwise just change to your preferred directory and your good to go.
The next thing I'd like to explore is automatically packing/minifying all CSS and Javascript into one file (or possibly outputting them directly to the layout in-line) and then caching the results of that to optimize bandwidth usage. If I ever have the luxury of that being a priority, that is 
New domain, mission statement
I've decided to change the name of this blog from zendframeworkhelp.com to leakingabstraction.com (leakyabstractions.com was of course taken).
I did this because the name implied that I am some Zend Framework guru -- which I am not, so I have changed the name to something more fitting. Of course, as I code and learn new things, I will post articles/tutorials here for all. Nothing changes are far as that goes.It felt a little bit arrogant to represent this website and myself as an expert when I am still learning so much from the true experts. Truthfully, my goal is to suck up as much knowledge as I can and then spit out all the good parts. The "tutorials" and "articles" section at the top will remain and I will continue to contribute to both, although there may be more general/opinion posts in the future.
If you want to know what inspired the name, have a read of this famous Joel on Software article.
Running scripts in Zend Framework
It's always been a bit confusing to me where and how to execute scripts within my Zend Framework applications. Often times I would just initialize the autoloader and the classes myself in the script file itself. Since the existence of Zend_Application, this has become a whole lot easier.
First, I create a folder called "scripts" in my application directory. This is an ideal location for scripts because it's outside of the Apache HTTP root which means we don't need to worry about remote execution. We can also easily point CRON jobs to this location instead of running some fangled CRON job to cURL a particular URL (Yes, I'm guilty of this, sadly).
Now, at the top of any script we write, add the following:
File: /application/scripts/anyscriptyouwrite.php
This sets our application environment to the "script" environment. Now, we will customize our Bootstrapper when running scripts by editing the index.php in the web root:
File: /public/index.php
$application->bootstrap('Db');
$application->bootstrap('Registry');
/* ..etc.. */
} else {
$application->bootstrap()
->run();
}
Notice, we don't ever call the run() method, so the front controller never gets instantiated. This allows us to explicitly declare each resource we want to setup an environment more ideal for scripting.
Another cool side effect of using the APPLICATION_ENV is we can specify script-specific settings in our application.ini:
File: /application/configs/application.ini
resources.db.adapter = PDO_MYSQL
resources.db.params.host = "hostname"
resources.db.params.username = "username"
resources.db.params.password = "password"
resources.db.params.dbname = "dbname"
Resources for Zend Framework
One of the most challenging aspects of the Zend Framework is that while there is a large volume of resources available for Zend Framework, sifting through this to get answers to specific problems can be tough. This is partially the fault of the nature of the framework -- a very uncoupled library means there is a lot of ways to implement it, many of them undocumented.
If you dig deep enough, though, you'll find that someone out there has probably tried to do whatever it is you are trying to accomplish -- or at least something like it. Here's my list of the top resources I use to reach solutions for my Zend Framework problems.
- The Reference Guide - Duh, right? It's #1 on my list, and it should be #1 on yours. If it isn't, are you sure you're reading it fully? I can't tell you how many newbies I've talked to that simply have not read the appropriate reference guide section on the functionality they are asking about. It's not perfect and it has some holes, but it is by far the most definitive resource.
- EDIT: As the much respected Matthew Weier O`Phinney points out in the comments, I've forgotten one of the best resources out there: The mailing lists. Take your pick or just sign-up to fw-general@. You may even end up with a reply from the author of the component you're dealing with.
- Stack Overflow - Stack Overflow is a Q&A site full of knowledgeable developers. My favorite part about Stack Overflow is developers that otherwise have no concrete online identity such as a blog or twitter will respond to posts. There are many knowledgeable "lurkers" who come out of the wood-works and often have clever solutions to problems that I wouldn't find on Google. Also, there are even some ZF contributors such as Bill Karwin who will personally respond to your questions.
- Surviving the deep end - After I read this, I could barely go back to my Zend apps in progress without completely restarting them from ground up. If MVC was ever unclear to you before reading this, read this now. Especially the section on controllers and models.
- Zend Framework in Action - Although intended for the Zend Framework 1.0 release, the concrete real-world examples it provides for some of the framework's most core classes (
Zend_Controller,Zend_Auth,Zend_Acl,Zend_Db) is still relevant. - IRC - This outdated protocol still thrives among hardcore developers, and PHP programmers are no exception. Join the #zftalk channel and ask your question. There are usually attentive and experienced users there who have probably ran into the problems you're facing. Several large ZF contributors also lurk here as well.
- Twitter - I'll admit, it's not my cup of tea but it's been a great resource for others. Ask your question, throw on the #zf hash tag, and cross your fingers.
- Blogs. Although most of the relevant ones will popup in a Google search, there's a couple I subscribe to regularly (that you can see on my links section to the right). If it's on my blogroll, it's because I feel any new post they make will be relevant and insightful. Each one is worth checking out.
- and last but not least... nothing explains the code in more detail than the code itself. One of the most important lessons you can ever learn in programming is nothing teaches you like diving into the code yourself. Although the task can seem daunting at first, it's often a better solution than an endless Google search or waiting for answer.
Anyways, hope this helps someone. Maybe eventually this site can be added to the list above !
Zend_Db: query(), fetch methods, and Zend_Db_Select
Zend_Db provides several methods for querying a database. They range from a simple query wrapper to programmatically. Say we have database object $db = Zend_Db_Table::getDefaultAdapter():
query() - Will return the results of any SQL query.
fetchRow() - Will return only the first row of the result set.
fetchCol() - Will return only one column (the first one if your select statement will be used) as an array.
fetchOne() - Will return only the value of the first column of the first row of the query.
These methods return row objects wherever possible (for query(), fetchRow(), and fetchCol()). You can change this to an array by setting the fetch mode before executing the SQL:
Or, if you just want to get your results as an array in the first place, you can use $db->fetchAssoc($query).
Creating queries programmatically with Zend_Db_Select
A Zend_Db_Select statement produces SQL that is correct based on the adapter you are using. It also takes care of things you probably don't ever bother to do when you write your own queries, such as deliberately expressing all tables along with their columns and properly escaping all table and column names. Zend_Db_Select ultimately returns this query, so usage is simple:
In this case, $db->select()->from('sample') returns the following string:
We can add parameters to our select statement easily:
$select->where('id=100');
$select->order('id DESC');
Which produces:
With a little more research, you will quickly discover that you can perform nearly any non-complex query with Zend_Db_Select.
When to use Zend_Db_Select and writing SQL directly
The first thing you probably took away from Zend_Db_Select (at least I did) is the fact that it makes writing really simple queries way more complicated than they should be.
And, well, you're right. It's hard to fight the instinct that using Zend_Db_Select feels like the right thing to do - it feels like it's the convention that a good programmer is supposed to follow. The reality is, for your application, you probably don't need to use it. Here's the list of conditions I came up with where I use Zend_Db_Select over writing the query directly.
- You are writing an application that needs to run on top of different types of RDBMS?
- You are writing a piece of code that you want to use in several different applications where the environments are unknown.
- You are writing a query that will be modified based on different logic conditions.
For the average application, you probably won't find yourself needing Zend_Db_Select that much. That said, when you do need it, nothing can beat it for the level of abstraction it provides.
Using Zend_Db standalone
If there is one class I had to pick out of the ZF library as the crown jewel, it would without a doubt be Zend_Db.
I rarely touch a PHP application or script that interacts with any database without utilizing this class.
Let's go over the quick list of why it's my fave:
- It automatically wraps PDO extensions and normalizes them as best as possible across different types of databases (in simple terms: change from a MySQL database to an MS SQL or PostgreSQL database with minimal code change)
- It sanitizes data input for you automatically (as long as you use it correctly)
- You can quickly grab results in array or object form without performing any post query operations.
- Provides methods for programatically creating queries
On top of that, it's easily decoupled from the rest of the library. Let's start out by ripping out Zend/Db.php and the Zend/Db folder and dropping it in our app.
Initializing the database connection
Now, in our settings / boilerplate file let's initialize the database adapter. The database adapter uses a lazy connection (meaning it doesn't actually connect to the database until you perform a query with it) by default. This makes the application settings a perfect place to setup our database object.
That's easy enough. If the application is simple and you plan on referencing the $db variable every time you want to make a query, you can stop right there. If you plan on using the database connection within a function or class scope, you don't have to re-initialize it every time (or use icky global variables). Zend_Db_Table comes with a static function for setting the default database adapter.
And now within our classes or functions, we can easily call it at any time:
Presto. Persistent database object any time we need it in our application / script.
Hacking Geshi syntax highlighter to recognize Zend Framework classes
This is kind of off-topic, but pretty neat. I was able to modify my Geshi WordPress plugin (called CodeColorer) to recognize Zend classes and link to the proper ZF Manual page. Example:
Zend_Acl Zend_Amf Zend_Application Zend_Auth Zend_Cache
Zend_Captcha Zend_CodeGenerator Zend_Config Zend_Config_Writer Zend_Console_Getopt
Zend_Controller Zend_Currency Zend_Date Zend_Db Zend_Debug
Zend_Dojo Zend_Dom Zend_Exception Zend_Feed Zend_File
Zend_Filter Zend_Form Zend_Gdata Zend_Http Zend_InfoCard
Zend_Json Zend_Layout Zend_Ldap Zend_Loader Zend_Locale
Zend_Log Zend_Mail Zend_Measure Zend_Memory Zend_Mime
Zend_Navigation Zend_OpenId Zend_Paginator Zend_Pdf Zend_ProgressBar
Zend_Queue Zend_Reflection Zend_Registry Zend_Rest Zend_Search_Lucene
Zend_Server Zend_Service Zend_Session Zend_Soap Zend_Tag
Zend_Test Zend_Text Zend_TimeSync Zend_Tool_Framework Zend_Tool_Project
Zend_Translate Zend_Uri Zend_Validate Zend_Version Zend_View
Zend_Wildfire Zend_XmlRpc ZendX_Console_Process_Unix ZendX_JQuery
It wasn't too tough to do either. Replace your Geshi library with this one or, if you want to use the same WordPress plugin as I'm using, download the entire CodeColorer plugin and extract to your WordPress plugins directory.
Note: I probably have not added all Zend class documentation links - I didn't recurse through the whole ZF library and add every class because most actually don't have a dedicated manual section. In most cases I only added the main parent class. I'll try to keep this as updated as possible with new ZF releases.
Last file update: January 5th, 2010
Download CodeColorer WordPress plugin
Download only Geshi library
Recent Posts
- Service layers explained simply
- Over-engineering syndrome and becoming results-oriented
- Part II: Managing CSS and JavaScript files within a Zend Framework App
Zend Framework Links
Twitter #zf
-
Clarion Door: @diffkid no, you'll have to monkey patch the class or store it on the way in #zf -
Clarion Door: @AdrianSchneider do share! #zf csrf protection ^^
-
Joó Ádám: RT @Tyr43l: set_error_handler in a library is evil. especially here http://bit.ly/bZQ27m this silently discards any warning below E_USER_ERROR #zf #fail -
Joe Devon: RT @Oleg Baranovsky Just a reminder #LAPHP talk is @Coloft on Sep 7; @kpschrade from #ZF is coming to LA: http://bit.ly/laphp-9-2010 -
Adrian Schneider: Added a plugin to automatically add CSRF protection to all delete links. Forms covered by Zend_Form already. Cool. #zf -
Cory Wiles: couldn't help but refactor small webservice app today. Took most of the day but much happier with separation of data layers and models. #zf -
Adrian Schneider: Taking a closer look at Zend_Log #ZF today. Really impressed with the benefits of combining filters and different writers (critical->email)
Archives
@ajbaird
- love when I go to post a #stackoverflow question and i figure out my answer just from typing out my question. stackoverflow = rubber duck 2010-08-04
- @saraashleydaly #imakeupmyownhashtags 2010-07-24
- @kristahiner http://bit.ly/8nkFl 2010-07-10
- More updates...
