Ah okay. So as far as I understand, ViewComposers don't really fit in my case. Because in my index fuction I get all stores, and in my show function I get a specific store. After that, I run some queries and do some calculations, which are a little bit similar, but nor really the same.

When I used to use Kohana, I would build specific View classes that extended the base View_Core class, so I could add a lot of view-related functionality to a more relevant class.

For example, asset management - this really isn't the controller's responsibility. A controller should not be managing what scripts, styles, etc have been added to a view, so I'd add this functionality to a specific View sub class, and instantiate that in the controller:

$this->view = new PageView($template);

This PageView class would then be responsible for adding or overriding its own scripts, styles etc, with a simple public API accessible from the controller:

$this->view->addScript($name);

The general way of doing things at the time was to add this kind of functionality to a Controller superclass, but that never sat well with me - why clog up all your action methods with a bunch of functions specific to views?

I'm just starting on Laravel (haven't built an app yet) but it seems to me that view composers fit into this kind of thinking - taking away view-specific functionality from controllers.

I've written in the comments on another site regarding View Composers and Creators that I think they're badly named; the functionality instead should be called called view filters, in the same way that Controllers have them. I think...

view($template, $data)
    ->before( /* function */)
    ->after(/* function */);

... makes much more sense than the current nomenclature.

It sounds like in your app that the controller should be doing the job of managing the store, but if you did want to make that dryer, an additional service provider would probably be the way here.