我已经阅读了许多资料，暗示 laravel 外观最终存在是为了方便，并且应该注入这些类以允许松散耦合。甚至Taylor Otwell 也有一篇文章解释了如何做到这一点。似乎我不是唯一一个对此感到疑惑的人。
use Redirect;
class Example class
{
public function example()
{
return Redirect::route("route.name");
}
}
会成为
use Illuminate\Routing\Redirector as Redirect;
class Example class
{
protected $redirect;
public function __constructor(Redirect $redirect)
{
$this->redirect = $redirect
}
public function example()
{
return $this->redirect->route("route.name");
}
}
这很好，只是我开始发现一些构造函数和方法开始采用四个以上的参数。
由于 Laravel IoC似乎只注入到类构造函数和某些方法（控制器）中，即使我有相当精简的函数和类，我发现类的构造函数正被所需的类打包，然后注入到需要的方法。
现在我发现如果我继续这种方法，我将需要我自己的 IoC 容器，如果我使用像 laravel 这样的框架，这感觉就像重新发明轮子？
例如，我使用服务来控制业务/视图逻辑，而不是处理它们的控制器——它们只是路由视图。因此控制器将首先获取其对应service的 ，然后是parameter其 url。一个服务功能还需要检查表单中的值，所以我需要Requestand Validator。就像那样，我有四个参数。
// MyServiceInterface is binded using the laravel container
use Interfaces\MyServiceInterface;
use Illuminate\Http\Request;
use Illuminate\Validation\Factory as Validator;
...
public function exampleController(MyServiceInterface $my_service, Request $request, Validator $validator, $user_id)
{
// Call some method in the service to do complex validation
$validation = $my_service->doValidation($request, $validator);
// Also return the view information
$viewinfo = $my_service->getViewInfo($user_id);
if ($validation === 'ok') {
return view("some_view", ['view_info'=>$viewinfo]);
} else {
return view("another_view", ['view_info'=>$viewinfo]);
}
}
这是一个例子。实际上，我的许多构造函数已经注入了多个类（模型、服务、参数、外观）。我已经开始将构造函数注入（如果适用）“卸载”到方法注入，并让调用这些方法的类使用它们的构造函数来注入依赖项。
有人告诉我，根据经验，方法或类构造函数的参数超过四个是不好的做法/代码异味。但是，如果您选择注入 laravel 外观的路径，我看不出如何真正避免这种情况。
我是不是把这个想法搞错了？我的课程/功能不够精简吗？我错过了 laravel 容器的意义还是我真的需要考虑创建自己的 IoC 容器？其他一些答案似乎暗示 laravel 容器能够消除我的问题？
也就是说，在这个问题上似乎没有明确的共识......