3.3. The Model Catalog

Normally, in Solar, you use Solar::factory() to create a new object instance. However, when working with models, you often need to instantiate the same model in different places. This uses up memory and CPU time to create what is essentially the same object multiple times.

The purpose of the model catalog is to have a single place where model objects are retained. Once a model object is instantiated through the catalog, the same model instance can be reused each time you need it.

3.3.1. Creating A Catalog Instance

To use a catalog, of course, you need an instance of it. By default, the Solar system registers a Solar_Sql_Model_Catalog object for lazy-loading under the name model_catalog. You can retrieve it like so:

<?php
$model = Solar_Registry::get('model_catalog');

As a matter of convention, we call the model catalog $model or $catalog, depending on the context. You can call it anything you like in your own scripts without harm, but as a matter of vocabulary, we recommend sticking with the convention.

3.3.2. Retrieving A Model From The Catalog

Now that we have a model catalog, we can use it to retrieve model object instances. It is almost as easy as this:

<?php
// get the catalog
$model = Solar_Registry::get('model_catalog');
// get the blogs model from the catalog
$blogs = $model->blogs;

However, there is one catch: you have to tell the catalog where the model classes are. Recall from the blog-demo chapter that we had to configure Solar_Sql_Model_Catalog in the config file like so:

<?php
$config['Solar_Sql_Model_Catalog']['classes'] = array('Acme_Model');

Thus, the above call to $model->blogs will cause the catalog to instantiate the class Acme_Model_Blogs and retain it as a property called blogs. The next time you ask for $model->blogs, the catalog will return the retained instance of the model object.



Local