Same Laravel resource controller for multiple rout

Question

I am trying to use a trait as a typehint for my Laravel resource controllers.

The controller method:

public function store(CreateCommentRequest $request, Commentable $commentable)

In which the Commentable is the trait typehint which my Eloquent models use.

The Commentable trait looks like this:

namespace App\Models\Morphs;

use App\Comment;

trait Commentable
{
   /**
    * Get the model's comments.
    *
    * @return \Illuminate\Database\Eloquent\Relations\MorphMany
    */
    public function Comments()
    {
        return $this->morphMany(Comment::class, 'commentable')->orderBy('created_at', 'DESC');
    }
}

In my routing, I have:

Route::resource('order.comment', 'CommentController')
Route::resource('fulfillments.comment', 'CommentController')

Both orders and fulfillments can have comments and so they use the same controller since the code would be the same.

However, when I post to order/{order}/comment, I get the following error:

Illuminate\Contracts\Container\BindingResolutionException
Target [App\Models\Morphs\Commentable] is not instantiable.

Is this possible at all?

Answer 1

So you want to avoid duplicate code for both order and fulfillment resource controllers and be a bit DRY. Good.

Traits cannot be typehinted

As Matthew stated, you can't typehint traits and that's the reason you're getting the binding resolution error. Other than that, even if it was typehintable, the container would be confused which model it should instantiate as there are two Commentable models available. But, we'll get to it later.

Interfaces alongside traits

It's often a good practice to have an interface to accompany a trait. Besides the fact that interfaces can be typehinted, you're adhering to the Interface Segregation principle which, "if needed", is a good practice.

interface Commentable 
{
    public function comments();
}

class Order extends Model implements Commentable
{
    use Commentable;

    // ...
}

Now that it's typehintable. Let's get to the container confusion issue.

Contexual binding

Laravel's container supports contextual binding. That's the ability to explicitly tell it when and how to resolve an abstract to a concrete.

The only distinguishing factor you got for your controllers, is the route. We need to build upon that. Something along the lines of:

# AppServiceProvider::register()
$this->app
    ->when(CommentController::class)
    ->needs(Commentable::class)
    ->give(function ($container, $params) {
        // Since you're probably utilizing Laravel's route model binding, 
        // we need to resolve the model associated with the passed ID using
        // the `findOrFail`, instead of just newing up an empty instance.

        // Assuming this route pattern: "order|fullfilment/{id}/comment/{id}"
        $id = (int) $this->app->request->segment(2);

        return $this->app->request->segment(1) === 'order'
            ? Order::findOrFail($id)
            : Fulfillment::findOrFail($id);
     });

You're basically telling the container when the CommentController requires a Commentable instance, first check out the route and then instantiate the correct commentable model.

Non-contextual binding will do as well:

# AppServiceProvider::register()
$this->app->bind(Commentable::class, function ($container, $params) {
    $id = (int) $this->app->request->segment(2);

    return $this->app->request->segment(1) === 'order'
        ? Order::findOrFail($id)
        : Fulfillment::findOrFail($id);
});

Wrong tool

We've just eliminated duplicate controller code by introducing unnecessary complexity which is as worse as that.

查看更多

0人赞 添加讨论(0) 举报

Answer 2

You can't typehint traits.

However, you can typehint interfaces. So you can create an interface that requires the methods from the trait and resolve that. Then have your classes implement that interface and you should be OK.

EDIT: As @Stefan has kindly pointed out, it's still likely to be difficult to resolve the interface to a concrete class because it will need to resolve to different classes under different circumstances. You could access the request in the service provider and use the path to determine how to resolve it, but I'm a bit dubious of that. I think putting them in separate controllers and using inheritance/traits to share common functionality may be a better bet, since the methods in each controller can type hint the required object, and then pass them to the equivalent parent method.