The problem of controller bloat can be solved by separating responsibilities: 1. Use Form Requests to extract verification logic; 2. Move complex business logic to Service class for processing; 3. Centrally manage the data access layer through Repository mode; 4. Use middleware to process pre-logic logic such as permissions and current limits; 5. Reasonably split the resource controller and hand it over to Blade or front-end components to process view logic. This keeps the controller simple and improves code maintainability and structural clarity.

In the Laravel project, if you find that the controller is getting bloated and full of various logic and database operations, you may have been trapped in the "Fat Controllers" problem. The core of solving this problem is to separate the code that does not belong to the controller, so that the controller is only responsible for receiving requests and returning responses.

Here are a few practical ways to help you keep your controller simple and clear.

Verify request data using Form Requests

Laravel provides a very convenient Form Request feature that can pull verification logic out of the controller. This not only reduces the amount of controller code, but also makes verification rules more centralized and reusable.

For example: If you have an interface to create an article, there are multiple fields that need to be verified for type, length, uniqueness, etc. You can use php artisan make:request StoreArticleRequest to create a Form Request class, and define rules and authorize methods.

Then your controller method can be simplified to:

 public function store(StoreArticleRequest $request)
{
    Article::create($request->validated());
    return redirect()->route('articles.index');
}

After doing this, the controller no longer cares about verification details and has clearer responsibilities.

Move business logic into Service class

When a large number of if-else, loops or complex business judgments appear in the controller, it means that this part of the logic should be encapsulated into a special service class (Service).

For example, when handling order status updates, points calculations, user permission changes, etc., you can extract a separate class, such as OrderService or UserService . The controller only needs to call the method of this service class.

Let's give a simple structural diagram:

 class OrderController extends Controller
{
    protected $orderService;

    public function __construct(OrderService $orderService)
    {
        $this->orderService = $orderService;
    }

    public function updateStatus(Order $order, Request $request)
    {
        $this->orderService->updateStatus($order, $request->input('status'));
        return back();
    }
}

This approach not only makes the controller lighter, but also makes business logic easier to test and maintain.

Manage data access layer with Repository mode

If you find that direct model queries appear frequently in the controller, such as User::where(...)->get() , and these queries may be reused in multiple places, it is a good idea to consider introducing the Repository pattern.

The role of Repository is to centrally manage data access logic to avoid excessive coupling between the controller and the model. You can create a corresponding Repository interface and implementation class for each main model.

for example:

 interface ArticleRepositoryInterface
{
    public function all();
    public function find($id);
    public function create(array $data);
}

class EloquentArticleRepository implements ArticleRepositoryInterface
{
    public function all()
    {
        return Article::all();
    }

    // Other implementations...
}

Then inject this interface into the controller:

 public function __construct(ArticleRepositoryInterface $articleRepo)
{
    $this->articleRepo = $articleRepo;
}

public function index()
{
    $articles = $this->articleRepo->all();
    return view('articles.index', compact('articles'));
}

The advantage of this is that when changing the data source or adding a cache layer in the future, the controller needs little change.

Tips: Other places to optimize

• The middleware processing pre-login logic : login inspection, permission verification, current limiting, etc. should be completed through middleware as much as possible.
• Reasonable splitting of resource controllers : If a single controller assumes too many responsibilities, consider splitting into multiple small controllers by function.
• The view logic is handed over to Blade or front-end components : do not splice HTML or format output content in the controller.

Overall, the key to avoiding Fat Controllers is separation of responsibilities. The controller shouldn't do much, it's just a bridge between the request and the response. Leveraging verification, business logic, and data access to appropriate components separately will make the entire project structure clearer and later maintenance will be much easier.

Basically that's it.

The above is the detailed content of Avoiding 'Fat Controllers' in Laravel.. For more information, please follow other related articles on the PHP Chinese website!