Pautas de construcción en CakePhp

$uses es un atributo que le permite acceder a modelos adicionales al que por defecto se encuentra definido. Si ponemos como ejemplo una aplicación como un blog. Por defecto solo se tiene acceso a modelo Post pero si se utiliza un código como el siguiente, se tendrá acceso al modelo Comment

<?php
class PostsController extends AppController {
var $name = 'Posts';
var $uses = array('Post', 'Comment');
}
>

Desde que Comment esta asociado a Post a través de una relación "tiene" , tu puedes acceder al modelo Comment a través de Post , como la manera siguiente.

$comments = $this->Post->Comment->findAllByPostId($id);

Esta relación en cadena se extiende de forma indefinida, incluyendo todos los modelos debajo de la línea. En ocasiones esto es muy ineficiente. Es necesario evitarlo en la manera de lo posible y utilizar otros medios para proporcionar la misma funcionalidad. Tener uno o dos modelos extras en su $uses no matara la aplicación pero incrementa el trabajo en torno a un 5% por cada modelo extra, así que con siete u ocho modelos extra, la página tardará en cargarse un 40% más.

Este comportamiento del modelo le permite filtrar y limitar las operaciones de búsqueda del modelo.El uso de Containable lo ayudará a reducir el desgaste innecesario de su base de datos, aumentando la velocidad y el rendimiento general de su aplicación. La clase también le ayudará a buscar y filtrar los datos para los usuarios de una manera limpia y consistente.

Containable permite agilizar y simplificar las operaciones sobre los enlaces de su modelo. Su acción consiste en la alteración temporal o permanentemente de las asociaciones de sus modelos. Esto lo hace mediante el uso de las contenciones suministradas para generar una serie de llamadas de bindModel y unbindModel. Para usar el nuevo comportamiento, puedes añadirlo a la propiedad $actsAs de su modelo:

class Post extends AppModel {
 var $actsAs = array('Containable');
}

Es una recomendación clara pero es bastante habitual olvidarla. El motor Cake genera dos secciones de cache. La primera es /tmp/cache/models. En ella, se describe un fichero por cada modelo que contiene la tabla schema de su sistema. La salida de las consultas se filtran si el nivel de debug es 0

La segunda cache es /tmp/cache/persistent. Hay una pareja de ficheros diferentes allí que son usados por Cake cuando se esta ejecutando la aplicacion. El fichero que causa que una deceleración en la ejecución es cake_core_file_map. Este fichero almacena las rutas de varias clases en la aplicacion. Para construir el fichero Cake utiliza la lógica para buscar por el árbol el fichero correcto. Si ponemos debug a 0 aumentamos el tiempo de expiración de estos archivos en el cache, lo cual es muy necesario en estos ficheros. Poniendo el debug aumentamos la expiración del cache a 999 días.

El Cache helper ayuda en el almacenamiento en cache de diseños(layouts) y vistas, ahorrando tiempo repetidamente en la recuperación de datos. View Caching en Cake, almacena temporalmente layouts y views con el motor de almacenamiento elegido. Cabe señalar que el Cache helper trabaja de manera muy distinta a otros "helpers". No tiene métodos que sean directamente llamados. En su lugar, una vista, es marcada con etiquetas de caché que indican que bloques de contenido no deben ser almacenados en cache.

Cuando se solicita la URL, Cake realiza controles para ver si esa cadena de solicitud ya se ha almacenado en cache. Si la tiene, el resto del proceso de envío de url es omitido. Todos los bloques nocache se procesan con normalidad. Esto provoca un gran ahorro en tiempo de tramitación de cada solicitud a una dirección URL en caché ya que se ejecuta como código mínimo. Si Cake no encuentra una vista en caché, o ha expirado para la URL solicitada prosigue para procesar la solicitud normalmente

Esto es bastante simple de configurar. En el controlador se debe añadir el atributo:

var $persistModel = true;

Después de una actualización de la página, verás que hay dos nuevos archivos en /tmp/cache/persistents para cada modelo incluido en el controlador. Uno de ellos es un caché del modelo y el otro es un caché de los objetos en la ClassRegistry. Al igual ViewCaching esta caché sólo se puede guardar en el archivo del sistema.

¿Cuánto ayuda? depende de su aplicación. Si el controlador tiene un solo modelo y no está asociado con ningún otro, no se va a ver mucha mejora. Si mi aplicación hay modelos que mantienen varias relaciones entre ellos el incremento de rendimiento es importante.