If Controller B does not interact with views, move it into a class of its own (not a controller class) and then you can just instantiate and use in Controller A or call it statically if appropriate.

Thank you flarpy... very simple !

how about refactoring your code. try the repository pattern.

Keep the controller only for the sake of preparing the request data and then returning the correct view,

You shall pass whatever data to the repository class to get a model merged with what ever data. You can implement the config values merging methods inside this class

astroanu said: Keep the controller only for the sake of preparing the request data and then returning the correct view,

Hi, I'm still learning Laravel and I don't know exactly what a reporitory class is... would you mind briefly explaining me through an example?

Alex

alzambo said:

Hi, I'm still learning Laravel and I don't know exactly what a reporitory class is... would you mind briefly explaining me through an example?

This tutorial https://bosnadev.com/2015/03/07/using-repository-pattern-in-laravel-5/ is a good walk through of using the repository pattern within Laravel.

Hi,

first of all a controller should only be the bridge between the user (interactions) with your business logic: receives data from the users, passes it to your business model and returns a response. Or it simply displays data to the user. This is the entire purpose of a controller in the MVC architectural pattern. So the way you describe Controller B could be a controller if lets say it's an API endpoint that only handles input/output for a certain type of data used by your business logic (independently) but you could also trigger requests to it from another controller (that depends on that type of data - via AJAX calls lets say). If this is not the case, then that's not a controller, it's just a part of your business logic.

You can access the controller by instantiating it and calling doAction: (put use Illuminate\Support\Facades\App; before the controller class declaration) $controller = App::make('\App\Http\Controllers\YouControllerName');
$data = $controller->callAction('controller_method', $parameters);

Also note that by doing this you will not execute any of the middlewares declared on that controller.

PS: the repository pattern has nothing to do with a controller, repository pattern should be used to separate the logic that retrieves the data and maps it to the entity model from the business logic that acts on the model.

ie: let's say you have an Order model that has the following functionality: add products on it, display products from it, calculate the price based on the products etc. All these functions represent your business logic. Now this Order needs to persist (in a database, in an in memory storage... whatever). This is where the repository pattern kicks in, in implementing the add/delete/update/get order method that will accept as input an Order object instance. So if today you'll use mysql lets say as your data storage, and tomorrow you decide to switch to mongoDB, by implementing the repository pattern you will only have to change the object that handles the persistence of your original business logic object - the order (by implementing the add/delete/update/get methods for the mongoDB server).