Tag Archives: Computing

Which Model Should Contain That Method?

Let’s say you have two models – each one modeling a database table – Users & Article. Here there’s nothing to deal with Zend Framwork, but you can think of them as typical models in a ZF application.

What happens if you have to write a getUserArticles method? Where would you put it? Whether this will be the User model or the Article model?Where?

Although technically you can put it in both models my advice is to look at the SQL query. If the FROM clause is containing the user table – than put the method in the User model, but here you’d have something like:

SELECT * FROM Article WHERE user_id = 1

I’d prefer to place it in the Article model!

Zend_Validate_Db_RecordExists in Zend Framework 1.10+

Zend_Validate_Db_RecodExists is an extremely useful validator in Zend Framework when you’d like to be sure that a give row exists. Now it seems to be even better. Before you could check for a specific row by only comparing a value to the specified column:

$validator = new Zend_Validate_Db_RecordExists('db_table_name', 'column_name');
if ($validator->isValid(122)) {
   ...
}

which made it useless when you’d like to compare by more than one column. Now this is changed and you can even exclude given rows by adding an exclude clause.

$validator = new Zend_Validate_Db_NoRecordExists(
    array(
        'table' => 'users',
        'field' => 'username',
        'exclude' => array(
            'field' => 'id',
            'value' => $user_id
        )
    )
);

Setting Up Global Cache in Zend Framework

In a large scale web application, especially based on Zend Framework, there are lot’s of components that support built in cache support. Such are Zend_Db, Zend_Translate, Zend_Date, etc. Also you may need cache support wherever in the app, so my advice is to setup a cache instance in the “beginning”, into the bootstrap.php or even better – into a front controller plugin, and to store it into the Zend_Registry. Thus you’ve to change only the lifetime for specific needs:

<?php
 
class CacheInit extends Zend_Controller_Plugin_Abstract
{
    public function __construct()
    {
        $frontendOptions = array(
            'automatic_serialization' => true,
            'lifetime' => 60
        );
 
        $backendOptions  = array(
            'cache_dir' => realpath(APPLICATION_PATH . '/../cache')
        );
 
        $cache = Zend_Cache::factory('Core',
                                     'File',
                                     $frontendOptions,
                                     $backendOptions);
 
        Zend_Registry::set('cache', $cache);
    }
}

Than add it as a front controller plugin:

// cache plugin
$frontController->registerPlugin(new CacheInit());

Zend Framework: Connect MySQL

There are so many tutorials about that, but let me add it one more time. You’ve to use the PDO_MYSQL adapter:

// where params include adapter, host
// username, password and dbname
$db = new Zend_Db_Adapter_Pdo_Mysql($params);

and set the default adapter

Zend_Db_Table::setDefaultAdapter($db);

That can be done in the bootstrap or into a front controller plugin!

Zend Framework: Cache Database Table Schemes

If you’re familiar with Zend Framework, you should know how to turn your database tables into models. Simply extend the Zend_Db_Table class. This is the very general example. There are lots of variations how to name the model classes and what member variables they can have.

<?
class User extends Zend_Db_Table
{}

The question is …

The question is how the framework knows what columns there are in a given table. That’s done by PHP on every call of the class, and the question is: isn’t that too slow? Yes it is and there’s a solution – to cache the table’s schema:

Zend_Db_Table_Abstract::setDefaultMetadataCache($cache);

Is there any problem?

Why it isn’t a default behavior when it’s so good? Because you’ve first to setup the cache, which is not always permitted – at least you’ve to have writing permissions. And on the second place if you’re rapidly developing the system and you change the database schema too frequently, you’ve to clear the cache every time. So it’s a good solution for the production server, but you can skip it while developing.