我正在为Laravel 5开发一个包,现在我需要从依赖注入中受益,以便有一个更可扩展和更可靠的应用程序,我不知道采用哪种方法最好,为什么,这是我的代码的一部分,我需要注入Lang类依赖项。
class MyController extends \App\Http\Controllers\Controller
{
public $text;
public $lang;
public function __construct()
{
// Some codes here
}
public function myFunction(){
$this->text = \Lang::get('package::all.text1');
}
}在这个链接中,建议使用http://laravel.com/docs/4.2/ioc 2方法,Basic Usage和Automatic Resolution是根据我对链接的理解提出的,这是我需要添加的第一个方法。
App::bind('lang', function($app)
{
return new \Lang();
}); 在应用程序的寄存器部分,然后在函数中,我将得到如下内容:
public function myFunction()
{
$lang = \App::make('lang');
$this->text = $lang::get('package::all.text1');
}另一种方法是修改constructor,如
public function __construct(Lang $lang)
{
$this->lang = $lang;
}然后从类类实例化对象
$myController = App::make('MyController');考虑到这个class是一个Controller,并且它将在routes文件中被调用,哪种方式是更好的方法,或者如果我对链接的理解不正确,请纠正我。还请告诉我,你为什么提出任何这些办法。
发布于 2015-03-03 15:08:41
应该注意的是,使用本地IoC解析($app->make() stylee)并不比直接使用外观(Lang::get() stylee)好多少--您仍然非常依赖Laravel的特定类,而没有真正让代码明确声明它需要这些精确的类。因此,一般的建议是,如果您希望您的代码尽可能可移植,应该尽可能多地将代码编码到一个接口上。
当然,在PHP开发中,这有几个很大的缺点:
LoggerInterface接口),所以您仍然必须依赖于接口的一个特定实例(在本例中,是Laravel的)。但无论如何,这是我对你的具体问题的想法。首先,我应该说,我还没有真正使用Laravel 5(只有4s),但我一直在跟踪它的发展。
如果我正在编写的类将大量使用给定的依赖项,或者作为类工作方式的核心部分,我将使用构造函数依赖项注入。这里的例子是控制器中的Request或某些Repository类,或者控制台命令类中的业务逻辑类。
如果我所需要的只是为了特定的目的(可能从控制器重定向并需要生成URI),我将解析来自IoC容器($this->app->make())的本地版本,然后使用它。如果我使用的是Laravel 5,并且该方法是由Laravel直接调用的(例如控制器的动作方法),我可能会使用方法注入,我不能100%确定。
最后,一般的建议是,如果构造函数方法签名由于大量依赖关系而变得太大:
$class->setRequest()方法而不是接受请求对象。这样做的缺点是,您需要告诉Laravel的IoC容器如何实例化对象(即必须调用这些setter)。这不是什么大问题,而是值得注意的事情。相关链接:
https://stackoverflow.com/questions/28834398
复制相似问题