[Catalyst] Making a hash available across the application

Tomas Doran bobtfish at bobtfish.net
Wed Mar 17 23:08:40 GMT 2010

On 17 Mar 2010, at 18:48, Ram Dobson wrote:
> I'm kinda new to Catalyst too, but i believe this is what one might  
> call a "helper" function. Anybody who knows more have an opinion on  
> the relative merit of my change?

Crapping stuff into the top level context class like that works,  
however as you do this you're throwing away reusability (as that stuff  
can now only be used inside Catalyst, not in anything else reusing the  
same database schema), and you're going towards making a 'god object'.

I'm not saying that doing something like this isn't _sometimes_ fine,  
but in this case, my mental model would consider the caching of some  
data values (which is basically what you're doing here) a function of  
the domain model layer, not of the web application per-se.

In fact, generally - you don't want to be calling the generic ->search  
method in your controllers _at all_.

The specific search functionality should instead be pushed down into  
your ResultSet classes, so that you say:


Rather than $c->model('DB::Books')- 
 >search({ %stuff_including_author_name }, { %ordering_stuff });

The former is your controller declaratively asking the domain model  
for what it wants. The latter is for controller manipulating the  
domain model directly by having knowledge of it's implementation.

Which tables you join (and how you join / sort / order / filter them)  
to get a set of data _IS NOT_ something controller code should know or  
care about, as that takes away your ability to alter the data  
representation (e.g. changing the table structure) without changing  
every place that knows about that representation...

When you need to change your schema (and this will happen!), then only  
having to change the implementation details in the model is  
significantly less work (and testing), especially when you have dozens  
of controllers!


More information about the Catalyst mailing list