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.
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.
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.