2013-08-23 23 views
15

Więc jestem nowy w frameworku Laravel od wersji 4 i zastanawiam się, jaki jest sposób tworzenia i używania kontrolerów RESTful. Czytając dokumentację, jestem trochę zdezorientowany co do różnicy między kontrolerami RESTful a kontrolerami zasobów.Laravel 4 definiujące kontrolery RESTful

Podczas definiowania relaksującego kontrolera, zgodnie z docs, to sugeruje, wykonując następujące czynności w routes.php:

Route::controller('posts', 'PostController'); 

W PostController, mamy zdefiniowanie metod klasy poprzedzając nazwę metody z HTTP czasownik, którego powinniśmy używać? Na przykład:

class PostController extends \BaseController { 
    public function getIndex() 
    { 
     // 
    } 
} 

jednak również nakreśla sposób tworzenia kontrolerów zasobów w pliku routes.php tak: Route :: zasobu (posty ', „PostController”);

I w PostController.php definiujemy metody bez poprzedzania ich czasownikiem HTTP.

class PostController extends \BaseController { 
    public function index() 
    { 
     // 
    } 
} 

Jaka jest różnica między tymi dwoma? A kiedy używamy jednego zamiast drugiego i dlaczego?

Ponadto, należy używać Route::controller('posts', 'PostController'); lub Route::resource('posts', 'PostController'); przejść routingu do sterownika lub należy określić za każdym route, jak poniżej:

Route::get('/users', '[email protected]'); 
Route::get('/users/create', '[email protected]'); 
Route::post('/users', '[email protected]'); 
Route::get('/users/{id}', '[email protected]'); 
Route::get('/users{id}/edit', '[email protected]'); 
Route::put('/users', '[email protected]'); 
Route::delete('/users', '[email protected]'); 
+0

Ten ostatni, Route :: resource, zgodnie z dokumentami - chyba że potrzebujesz więcej kontroli. :) –

+0

Używanie 'Route :: controller ('posts', 'PostController');' nie powinno być używane do tworzenia kontrolerów RESTful? Nie powinniśmy również poprzedzać metodami kontrolera odpowiednim czasownikiem HTTP? Zdaję sobie sprawę, że ostatnie pytanie prawdopodobnie nie jest odpowiednie dla tego formatu, ponieważ jest subiektywne. – Iain

Odpowiedz

34

Właśnie ten regulator np

<?php 

class TestController extends BaseController { 

    public function getIndex() 
    { 
     echo "a"; 
    } 

    public function postSecond($a) 
    { 
     echo "b"; 
    } 

} 

W trasy, jeśli masz:

Route::controller('tests', 'TestController'); 

Wykonaj e

php artisan routes 

Musisz mieć:

+--------+--------------------------------------------+------------------------+-----------------------------------+----------------+---------------+ 
| Domain | URI          | Name     | Action       | Before Filters | After Filters | 
+--------+--------------------------------------------+------------------------+-----------------------------------+----------------+---------------+ 
|  | GET /tests/index/{v1}/{v2}/{v3}/{v4}/{v5} |      | [email protected]   |    |    | 
|  | GET /tests         |      | [email protected]   |    |    | 
|  | POST /tests        | tests.store   | [email protected]    |    |    | 
|  | GET /tests/{_missing}      |      | [email protected]  |    |    | 
+--------+--------------------------------------------+------------------------+-----------------------------------+----------------+---------------+ 

laravel kontroluje kontroler i generuje trasy w oparciu o jakie metody stwierdzi, automatycznie.

Ale jeśli nie

Route::resource('tests', 'TestController'); 

Dostaniesz tę listę trasy:

+--------+--------------------------------------------+------------------------+-----------------------------------+----------------+---------------+ 
| Domain | URI          | Name     | Action       | Before Filters | After Filters | 
+--------+--------------------------------------------+------------------------+-----------------------------------+----------------+---------------+ 
|  | GET /tests         |      | Closure       |    |    | 
|  | GET /tests         | tests.index   | [email protected]    |    |    | 
|  | GET /tests/create       | tests.create   | [email protected]    |    |    | 
|  | POST /tests        | tests.store   | [email protected]    |    |    | 
|  | GET /tests/{tests}       | tests.show    | [email protected]    |    |    | 
|  | GET /tests/{tests}/edit     | tests.edit    | [email protected]    |    |    | 
|  | PUT /tests/{tests}       | tests.update   | [email protected]    |    |    | 
|  | PATCH /tests/{tests}      |      | [email protected]    |    |    | 
|  | DELETE /tests/{tests}      | tests.destroy   | [email protected]   |    |    | 
+--------+--------------------------------------------+------------------------+-----------------------------------+----------------+---------------+ 

Nie zgadywać, laravel używa predefiniowaną listę CRUD tras, można usunąć niektóre z tych tras, ale nie sprawdzi kontrolera, aby zbudować trasy dla twoich metod.

Ty decydujesz, co jest dla Ciebie najlepsze. Ale zwykle, jeśli twój kontroler to CRUD, dobrym początkiem jest Route :: resource(), poza tym możesz użyć kontrolera Route ::() lub zbudować trasy ręcznie.

EDIT:

Nie ma naprawdę dlaczego jeden lub dlaczego innego, to tylko kwestia projektu i wyboru. Niektórzy nigdy z nich nie skorzystają. To tylko kapelusz Route::resource() podąża za routingiem Railsów: http://guides.rubyonrails.org/routing.html.

Korzystanie Route::resource() nie trzeba tworzyć wszystkie te metody, ale będziesz skończyć z listą tras bezcelowe, ponieważ laravel zawsze stworzyć wszystkie z nich domyślnie, chyba że robisz:

Route::resource('photo', 'PhotoController', 
       array('only' => array('index', 'show'))); 

Lista Twoich tras wyświetli tylko indeks i pokaż akcje.

Ponadto, jeśli potrzebujesz innych tras, używając Route::resource(), musisz je zbudować ręcznie lub wykonać trochę magii, aby były automatyczne dla wszystkich zaradnych tras. Korzystanie z funkcji Route::controller() odbywa się automatycznie, za każdym razem, gdy dodajesz nową metodę, tworzona jest dla ciebie nowa trasa.

Ponownie, jeśli masz sterownik CRUD do zbudowania, zacznij od użycia Route::resource(). W przeciwnym razie pomyśl o korzyściach wynikających z tego czy innego w danym przypadku.

EDIT2:

Jest to świetny artykuł z Philem jesiotra (PyroCMS i PHP-rys), o korzyściach płynących z ręcznie zbudować wszystkich trasach: http://philsturgeon.co.uk/blog/2013/07/beware-the-route-to-evil.

+0

Nie jestem zbyt pewien, że rozumiem twoją odpowiedź. Dlaczego miałbym używać 'Route :: controller' zamiast' Route :: resource', jeśli obydwoje osiągną to samo? 'Route :: controller' wydaje się być bardziej skomplikowanym procesem, aby skonfigurować kontroler RESTful, ponieważ wymaga on zerwania konwencji i przedrostowania metod kontrolera za pomocą czasownika HTTP. Czy istnieje jakikolwiek powód, aby użyć go w 'Route :: resource'? Jeśli używam 'Route :: resource', nie muszę mieć metod kontrolera dla indeksu, tworzyć, przechowywać, pokazywać, edytować, aktualizować i niszczyć czy mam? Dodanie lub usunięcie metod do tego odzwierciedli się w dostępnych trasach? – Iain

+0

Po prostu edytowane w celu wyjaśnienia. –

+3

Kolejna edycja, aby dodać link do artykułu. –

5

@ Odpowiedź Antonio jest dobra. Pozwól mi powiedzieć coś podobnego i ważnego trochę bardziej zwięźle. W routes.php:

Route::resource('users', 'UserController'); 

Stosując metodę zasobów sprawia laravel zakładać funkcjonalność CRUD i wygląda tylko dla sześciu, gotowych metod CRUD: indeks, tworzenie, przechowywanie, pokaz, zniszczyć, itd. To won” t "zobacz" wszelkie inne, nowe metody, które tam tworzysz.

Route::controller('info', 'InfoController'); 

Użycie metody kontrolera umożliwia tworzenie niestandardowych metod/stron. Laravel wyszukuje je, gdy wstawiasz nazwę metody/strony za pomocą czasownika HTTP. W swoim XxxxController.php:

class InfoController extends \BaseController { 

    public function getFeatures() 
    { 
     return View::make('info.features'); 
    } 

    public function getContactUs() 
    { 
     return View::make('info.contact-us'); 
    } 

    public function getPricing() 
    { 
     return View::make('info.pricing'); 
    } 

} 
+0

Dużo wyraźniej, mniej słów – Yash