2017-03-15 18 views
3

私はコントローラとモデルを可能な限りスリムに保つためにLaravelに依存性注入をしようとしています。目標は、特定のモデルに起因するデータのフェッチを処理するためのリポジトリを持つことです。この目的を達成するために Laravel Controller Dependency Injection

は、私はドキュメント here、人気Laravelの定型 here

からの例に従うことをしようとしている。しかし$userがどこから来ている私は理解していません。

だから我々は2つのファイルを持っている定型を見て:ProfileControllerhere

抜粋を下に

use App\Repositories\Frontend\Access\User\UserRepository; 
/** 
* Class ProfileController. 
*/ 
class ProfileController extends Controller 
{ 
    /** 
    * @var UserRepository 
    */ 
    protected $user; 
    /** 
    * ProfileController constructor. 
    * 
    * @param UserRepository $user 
    */ 
    public function __construct(UserRepository $user) 
    { 
     $this->user = $user; 
    } 

これは、ドキュメントに記載された依存性注入のようにたくさん見えます、これは次のとおりです。

class UserController extends Controller { 

    /** 
     * The user repository instance. 
     */ 
     protected $users; 

     /** 
     * Create a new controller instance. 
     * 
     * @param UserRepository $users 
     * @return void 
     */ 
     public function __construct(UserRepository $users) 
     { 
      $this->users = $users; 
     } 

私の問題は、$userがどこから来ているのか分かりません。

UserRepositoryには、クラスそのもののパラメータとして$ユーザーが定義されていません。どこのコードにはAuth::user()がないので、ユーザーインスタンスがどこから来ているのか混乱しています。

+0

'$ user'は変数の名前です。 '$ biggieSmalls'やその他のものもあります。変数は単に 'UserRepository'のインスタンスを保持します。 – devk

+0

LaravelのDICは、コントローラが必要とするため、LICKを作成します。 – bassxzero

+0

@devkそのインスタンスは変数にどこに割り当てられていますか?私はそれが何かに名をつけることができると理解していますが、どこに割り当てられているのか分かりません。それはタイプヒントではないのですか? –

答えて

5

Laravel依存性注入では、Containerによって処理されます。私は単純化していますが、コンテナをオブジェクトのソースとして考えることができます。シングルトンがある場合、そのシングルトンはコンテナに格納されます。それ以外の場合、コンテナはオブジェクトをインスタンス化する方法を知っています。 Laravelが(コントローラのような)メソッドを呼び出したり、オブジェクトをインスタンス化したりすると、コンストラクタを調べて、ヒント依存の型を探します。依存関係がある場合は、それを取得または作成する方法を知っていて、それを行い、それを渡します。

Laravelはそれがコンストラクタ

public function __construct(UserRepository $user) 
{ 
    $this->user = $user; 
} 

見コントローラをインスタンス化するときに、コンテナは、それはあなたのために新しいものをインスタンス化しますので、それはUserRepositoryが必要であることを確認するためにタイプヒンティングを使用しています。これも再帰的に行います。したがって、新しいUserRepositoryを作成すると、そのコンストラクタを参照して、RoleRepositoryが必要であることがわかります。

TLDR:サービスコンテナが依存関係を検査し、それらのインスタンスをインスタンス化します。

+0

それは意味があります。そして、リポジトリは、渡されている電子メールに基づいてどのユーザーが「Auth :: user();」を使っているのか分かりませんが、私の次の割り当てだと思います!ありがとうございました:) –

+0

セッターを使用して設定する必要があるクラスの注入についてはどうですか? zend framework 2.4と同じ工場パターンがありますか?ありがとうございます – xiarnousx

+0

@xiarnousx私はZend Frameworkに慣れていないので、どのように比較するのかはわかりませんが、オブジェクトを[コンテナにバインド]する方法を定義できます(https://laravel.com/docs/ 5.5/container#binding-basics)そして、Laravelは、オブジェクトを注入するよう要求したときにそのクロージャを使ってオブジェクトを構築します。 – jfadich

2

Laravelの怪しげな魔法にようこそ。これらの依存関係注入に関する基本的な考え方は、あなたのルート&コントローラをどのように定義するかに応じて、URLの自動解析、URL内のIDの識別、およびオブジェクトのデータベースフェッチを実行できることです。

私の問題は、$ユーザーがどこから来ているのか分かりません。

おそらくdocs on the service containerを読んでください。

私のプロジェクトの一つで
php artisan route:list 

、これはこの出力になり:

+--------+-----------+----------------------------+--------------------+-------------------------------------------------+--------------+ 
| Domain | Method | URI      | Name    | Action           | Middleware | 
+--------+-----------+----------------------------+--------------------+-------------------------------------------------+--------------+ 
|  | GET|HEAD |/      |     | Closure           | web   | 
|  | GET|HEAD | api/user     |     | Closure           | api,auth:api | 
|  | GET|HEAD | categories     | categories.index | App\Http\Controllers\[email protected] | web   | 
|  | POST  | categories     | categories.store | App\Http\Controllers\[email protected] | web   | 
|  | GET|HEAD | categories/create   | categories.create | App\Http\Controllers\[email protected] | web   | 
|  | GET|HEAD | categories/{category}  | categories.show | App\Http\Controllers\[email protected] | web   | 
|  | PUT|PATCH | categories/{category}  | categories.update | App\Http\Controllers\[email protected] | web   | 
|  | DELETE | categories/{category}  | categories.destroy | App\Http\Controllers\[email protected] | web   | 
|  | GET|HEAD | categories/{category}/edit | categories.edit | App\Http\Controllers\[email protected] | web   | 
|  | GET|HEAD | products     | products.index  | App\Http\Controllers\[email protected] | web   | 
|  | POST  | products     | products.store  | App\Http\Controllers\[email protected] | web   | 
|  | GET|HEAD | products/create   | products.create | App\Http\Controllers\[email protected] | web   | 
|  | GET|HEAD | products/{product}   | products.show  | App\Http\Controllers\[email protected]  | web   | 
|  | PUT|PATCH | products/{product}   | products.update | App\Http\Controllers\[email protected] | web   | 
|  | DELETE | products/{product}   | products.destroy | App\Http\Controllers\[email protected] | web   | 
|  | GET|HEAD | products/{product}/edit | products.edit  | App\Http\Controllers\[email protected]  | web   | 
+--------+-----------+----------------------------+--------------------+-------------------------------------------------+--------------+ 

そして、すべてをあなたはまた、あなたのルートの定義は、このコマンドを使用してパラメータを含んだURLをに変換する方法の良いアイデアを得ることができますそれらのルートとそれらのurisとパラメータは、非常に単純なルート定義から生成されます。

$ cat routes/web.php 
<?php 

Route::get('/', function() { 
    return view('master'); 
}); 

Route::resource('products', 'ProductController'); 
Route::resource('categories', 'CategoryController'); 

あなたは上記のルート出力のURIのリストを見れば、あなたは{カテゴリ}{製品}のようなURIで指定されたパラメータが表示されます。ここに私のルートファイルです。これらは、Laravelが識別するURIのID /キーに対応します。 Laravelは、私のコントローラファイルを見て、さまざまな機能のタイプヒントを見て、私の機能がうつ状態を注入することを期待していることを検出するのに十分なほどスマートです。例えば

、カテゴリーコントローラの方法は次のようになりますを示しています。

public function show(Tree $category) 
{ 
    var_dump($category); 
} 

私のコントローラは、少し変わったように見えるかもしれません私は型ツリーのオブジェクトをしたいタイプヒンティングんだけど、Laravelはあるので、私は実際にタイプツリーのモデルが必要なことを認識するのに十分なスマートなので、URLを解析してIDを見つけ、自動的にdbテーブルのレコードを取得します idは{私の機能にそれを注入します。

私が$ categoryの代わりに入力パラメータ$ treeの名前をつけようとしたとき、私はhad some troubleに注意してください。その他のスレッドはあなたの質問にもちょっと答えるのに役立ちます。

結論として、Laravelは自分のコードとクエリを手動で定義して目的のオブジェクトを取得するという面倒な作業から解放されるように、多くの「魔法」を実行しています。

関連する問題