CODEWITHSUNDEEP
laravellaravel-5code-reuse
user13134426
user13134426

Reputation:

How manage classes in controller in laravel?

I am currently working on a project which is now expands too much so now every controller's top of project look like this.

use App\Helpers\Comments_Helper;
use App\Helpers\GetDeliveryRun_Helper;
use App\Helpers\Histories_Helper;
use App\Helpers\Notification_Helper;
use App\Helpers\Tables\TableHistory;
use Illuminate\Support\Facades\Queue;
use App\Helpers\Tables\TableManifest;
use App\Helpers\Tables\TableManifestConsignment;
use App\Http\Controllers\Controller;
use App\Models\Address;
use App\Models\Consignment;
use App\Models\Customer;
use App\Models\ConsignmentManifest;
use App\Models\Manifest;
use Auth;
use DB;
use File;
use Barryvdh\DomPDF\Facade as PDF;
use Illuminate\Http\Request;
use PhpOffice\PhpSpreadsheet\IOFactory;
use App\Jobs\ManifestPOD\ConsignmentDownload;
use App\Jobs\ManifestPOD\ConsignmentZipper;
use Maatwebsite\Excel\Facades\Excel;
use Response;

is there any way to declare these classed globally and use it in every controller. what is best programming practice for this problem

Upvotes: 0

Views: 112

Answers (3)

puncoz
puncoz

Reputation: 496

These are the dependencies classes used in that controller. You can globally autoload all those namespaces in composer file. But that is not recommended.

From the screenshot, I can sense that you have one of the worstly planned structure of code. Here your controller classes look like a God Class

All of your logic could be extracted from your controller to another class (single responsible service class or action class). That way your controller class could be well managed with skinny methods and fewer dependencies.

If you are interested, I have created one laravel boilerplate with organized nested folder structures. PS: I prefer nested directory over flat, but you can go with a flat directory as well.

https://github.com/puncoz-official/laravel-boilerplate

Upvotes: 0

thefallen
thefallen

Reputation: 9749

I agree with Nico Haase, but if you still want to shorten the imports you can do it for the Helpers and Models namespace. Instead of importing every model you can instead import use App\Models; and then in the places where you use a class from that namespace you can do Models\Address, Models\Consignment, etc. You can do the same for the Helpers namespace. Also use facades like this \Auth, \DB, etc. instead of importing.

Upvotes: 0

Nico Haase
Nico Haase

Reputation: 12095

If that is the list of used classes in your controller, then you are using controllers wrong: why not put such stuff in other classes and reduce the code in the controller to the minimal parts: evaluate the input, pass it to other(!) services that compute a result, and return the result.

This technique of decoupling makes your services testable. For example, how would you test the PDF or Excel generation from within the controller? By constructing a request first? No, probably such a generation needs only tiny parts of all the stuff you do in the controller. And should that generation be directly coupled to the database, such that you need to create database entities first to generate a PDF? No, read such stuff from the DB, create data objects, and pass them to the consuming services - and all of a sudden, you can create DTOs in a test, pass them to the Excel generation, and check whether that works without crafting a request object or seeding the database with fixtures

Upvotes: 2

Related Questions