在Laravel中从另一个控制器调用控制器是一种好习惯吗? [英] Is calling a Controller From Another Controller a good practice in Laravel?

问题描述

我能够使用可重用的 postPayment()方法实现 PaypalController ，该方法接受商品及其价格，并创建Paypal付款，然后重定向到贝宝付款页面.

I was able to implement a PaypalController, with a reusable postPayment() method, which accepts items and their prices, and creates a Paypal payment, and redirects to a Paypal payment page.

class PaypalController extends Controller {

    private static $_api_context;

    private static function initialize() {
        //initialize api context
    }

    public static function postPayment($items, $currency, $description) {
        self::initialize();

        //create item list, transaction, payment objects, etc

        $payment->create(PaypalController::$_api_context);
        ...
        return redirect()->away($redirect_url); // redirect to paypal
    }
}

PaypalController 由其他控制器静态调用.例如， AuthController 可能会调用它以在用户注册到我的网站后立即向用户请求付款:

PaypalController is called statically by other controllers. For example, the AuthController might call it to request payment from the user right after the user registers to my site:

class AuthController extends Controller {
    public function postRegister(Request $request) {
        return PaypalController::postPayment($items, 'JPY', 'description');
    }
}

基本上， PaypalController 返回 Redirect 到 AuthController ，该代码也将其返回，以执行重定向到Paypal付款页面的操作.

Basically, PaypalController returns a Redirect to AuthController, which also returns it, to perform the redirect to the Paypal payment page.

我想知道这是否是一个好的设计-一个控制器调用了另一个控制器，对吗?

I was wondering if this is a good design - a controller calling a different controller, is it?

如果没有，哪种更好的方法呢?也许将我的代码从PaypalController移到自定义服务提供商，自定义助手或其他东西?我是Laravel的新手，希望能提供一些指导.

If not, what would be a better way to do this? Maybe move my code from PaypalController into custom Service Provider, or custom Helper, or something else? I am very new to Laravel, and I would appreciate some guidance.

推荐答案

不，这不是一个好习惯.您应该将业务逻辑抽象到服务/存储库类.例如:

No it's not a good practice. You should abstract the business logic to a service/repository class. So for example:

创建一个接口作为Contract:

Create an interface as Contract:

namespace App\Services\Paypal;

interface PaypalInterface {

     public function PostRegister(Array $array, /*More $params if necessary*/); 
}

然后执行合同:

namespace App\Services\Paypal;

class PaypalService implements PaypalInterface {

    // Must match the method signature declared in the interface
    public function PostRegister(Array $array, /*$More $params if necessary*/) {

        // Do the process here
    }
}

然后使用协定/接口作为依赖项.因此，在您的 PaypalController 或任何其他控制器中，您都可以像这样使用它:

Then use the contract/interface as dependency. So, in your PaypalController or in any other Controller you may (re)use it like:

namespace App\Http\Controllers;

use App\Http\Request;
use App\Services\Paypal\PaypalInterface;

class AuthController extends Controller {
    public function postPayment(Request $request, PaypalInterface $paypalService) {
        return $paypalService->postRegister($request->all());
    }
}

在这种情况下，在服务提供商中注册绑定(实现的接口)(基本上在 AppServiceProvider 中).这是基本的工作流程.为什么要使用接口，因为控制器(客户/消费者类)应该与合同/接口对话，而不是具体的实现.

In this case, register the binding (interface to implementation) in a service provider (Basically in AppServiceProvider). That's the basic workflow. Why an interface because, Controllers (Client/Consumer classes) should talk to Contract/Interface instead of a concrete implementation.

我的这篇文章可能会对您有所帮助，但请记住，这并不是100％分离的，它是仍然与 Laravel 框架结合在一起，您甚至可以进一步取消服务的耦合.

This article of mine may help you but remember this is not the 100% decoupled, it's still coupled with Laravel framework and you can even more decouple the Service.

注意:这是最佳做法，但不要盲目地对每个项目/问题都采用这种方法，只是在明智地选择时才这样做，这实际上取决于具体情况，而不仅仅是为此而死.当前的上下文可以很好地遵循此要求.

这篇关于在Laravel中从另一个控制器调用控制器是一种好习惯吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！