The below code is a little shorter but does the same thing

10 min cache

$users = Cache::remember('users', 10, function() {
    return User::get();
});

cache forever but attach a tag so you can flush it

$users = Cache::tags('user')->rememberForever('users', function() {
    return User::get();
});


Cache::tags('user')->flush();

source: http://laravel.com/docs/cache

I don't thing stuff like caching should be in a presenter, a presenter to me is a class that formats 1.66666 into € 1.67

My repositories handle the cache. I usually cache every thing with rememberForever() and flush the cache based on tags when CRUD the same type of object

zenry said:

I don't thing stuff like caching should be in a presenter, a presenter to me is a class that formats 1.66666 into € 1.67

My repositories handle the cache. I usually cache every thing with rememberForever() and flush the cache based on tags when CRUD the same type of object

The design pattern we're thinking of is a Decorator (http://en.wikipedia.org/wiki/Decorator_design_pattern), of which a Presenter is a subset.

zenry said:

I don't thing stuff like caching should be in a presenter, a presenter to me is a class that formats 1.66666 into € 1.67

My repositories handle the cache. I usually cache every thing with rememberForever() and flush the cache based on tags when CRUD the same type of object

I would be interested in seeing some code examples in the context of the actual files you use them in.

I don't like the idea of mixing both cache and data persistence/fetching. I haven't done much yet in regards of caching but I've thought about creating a Cached[Resource]Repository which decorates a concrete implementation of a repository contract.

I've wrote a quick snippet to show you what I think I'll be doing (or along the lines of), for my project, you can see that here

This is a much more ideal solution than putting the caching AND fetching in one place, I create a new implementation of ProductRepositry I don't want to rewrite the caching layer.