Laravel - เส้นทาง :: ทรัพยากรเทียบกับเส้นทาง :: ตัวควบคุม


144

ผมอ่านเอกสารบนเว็บไซต์ Laravel, Stack มากเกินและ Google แต่ยังคงไม่เข้าใจความแตกต่างระหว่างและRoute::resourceRoute::controller

หนึ่งในคำตอบกล่าวว่า Route :: resource มีไว้สำหรับ crud อย่างไรก็ตามด้วยตัวควบคุม Route :: เราสามารถทำสิ่งเดียวกันกับทรัพยากร Route :: และเราสามารถระบุเฉพาะการกระทำที่จำเป็นเท่านั้น

พวกเขาดูเหมือนพี่น้อง:

Route::controller('post','PostController');
Route::resource('post','PostController');

เราจะเลือกสิ่งที่จะใช้อย่างไร? การปฏิบัติที่ดีคืออะไร?


12
เป็นเพียงหมายเหตุสำหรับผู้ใช้ Laravel 5.2 ในขณะที่ตัวควบคุมโดยนัยจะเลิกใช้งาน
รอย

คำตอบ:


296

ตัวควบคุมทรัพยากรที่เหลือ

สงบควบคุมทรัพยากรชุดเส้นทางเริ่มต้นบางอย่างสำหรับคุณและแม้กระทั่งชื่อพวกเขา

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

ให้เส้นทางที่มีชื่อเหล่านี้แก่คุณ:

Verb          Path                        Action  Route Name
GET           /users                      index   users.index
GET           /users/create               create  users.create
POST          /users                      store   users.store
GET           /users/{user}               show    users.show
GET           /users/{user}/edit          edit    users.edit
PUT|PATCH     /users/{user}               update  users.update
DELETE        /users/{user}               destroy users.destroy

และคุณจะตั้งค่าคอนโทรลเลอร์ของคุณแบบนี้ (actions = method)

class UsersController extends BaseController {

    public function index() {}

    public function show($id) {}

    public function store() {}

}

คุณยังสามารถเลือกได้ว่าจะรวมหรือยกเว้นการดำเนินการใดดังนี้

Route::resource('users', 'UsersController', [
    'only' => ['index', 'show']
]);

Route::resource('monkeys', 'MonkeysController', [
    'except' => ['edit', 'create']
]);

เอกสาร RESTful Resource Controller


ตัวควบคุมโดยปริยาย

ควบคุมโดยปริยายมีความยืดหยุ่นมากขึ้น คุณได้รับการกำหนดเส้นทางไปยังวิธีการควบคุมของคุณตามประเภทคำขอ HTTP และชื่อ อย่างไรก็ตามคุณไม่มีชื่อเส้นทางที่กำหนดไว้สำหรับคุณและจะจับโฟลเดอร์ย่อยทั้งหมดสำหรับเส้นทางเดียวกัน

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

จะนำคุณไปสู่การตั้งค่าคอนโทรลเลอร์ด้วยรูปแบบการตั้งชื่อ RESTful:

class UserController extends BaseController {

    public function getIndex()
    {
        // GET request to index
    }

    public function getShow($id)
    {
        // get request to 'users/show/{id}'
    }

    public function postStore()
    {
        // POST request to 'users/store'
    }

}

เอกสาร Implicit Controller


เป็นแนวทางปฏิบัติที่ดีในการใช้สิ่งที่คุณต้องการตามความต้องการของคุณ ผมเองไม่เหมือนควบคุมโดยปริยายphp artisan routesเพราะพวกเขาสามารถยุ่งไม่ได้ให้ชื่อและสามารถทำให้เกิดความสับสนเมื่อใช้ โดยทั่วไปฉันจะใช้ตัวควบคุมทรัพยากร RESTfulร่วมกับเส้นทางที่ชัดเจน


1
หากเราใช้เส้นทางทรัพยากรหลายเส้นทาง (อาจจะดัชนีแสดง) ทำไมไม่ใช้เส้นทางคงที่ Route :: get (... )? ฉันคิดว่ามันไม่ได้ดีไปกว่าการใช้ array ('only' => array ('index', 'show') และวิธีใดที่ใช้สำหรับคอนโทรลเลอร์ RESTFull เมื่อเราร้องขอบางสิ่งเช่น 'user / 123', getIndex () ใช้ได้กับ 'user /' แต่ด้วย user / 123 ฉันได้รับข้อผิดพลาด NotFoundHttpException (ลองใช้ชื่ออื่น getView และอื่น ๆ ใช้งานได้เฉพาะเมื่อประกาศเป็น Controller @ getView) หรือไม่
Sonique

ใครช่วยชี้แจงได้ว่า 'resource.edit' มีไว้เพื่ออะไร มันเป็นวิธีการ GET ดังนั้นฉันคิดว่ามันควรจะเป็นข้อมูลเต็มรูปแบบในทรัพยากรแทนที่จะเป็นเพียงข้อมูลที่ จำกัด ผ่าน 'resource.show'?
Anthony

1
@Anthony - resource.editคือการแสดงมุมมองการแก้ไขโดยพื้นฐานแล้วเป็นแบบฟอร์มสำหรับแก้ไขทรัพยากรที่มีอยู่
ryanwinchester

@fungku น่าสนใจ .. คุณกำลังบอกว่า resource.edit จะส่งคืน HTML แทน JSON จริงหรือ?
Anthony

2
@Anthony โดยทั่วไป (และเท่าที่ฉันรู้) ใช่ resource.editและresource.createโดยทั่วไปจะใช้สำหรับ UI ... แสดงมุมมองด้วยรูปแบบ HTML แบบฟอร์มเหล่านั้นจะ PUT / POST เป็นresource.updateและresource.storeตามลำดับ หากคุณไม่ได้ทำเช่นนั้นคุณสามารถเพิกเฉยต่อพวกเขาและกำจัดวิธีการแก้ไข () และสร้าง () ในคอนโทรลเลอร์ของคุณ
ryanwinchester

3

สำหรับวิธีการควบคุมเส้นทางเราต้องกำหนดเส้นทางเดียวเท่านั้น ในวิธีรับหรือโพสต์เราต้องกำหนดเส้นทางแยกกัน

และวิธีการทรัพยากรใช้เพื่อสร้างเส้นทางหลายเส้นทางเพื่อจัดการกับการกระทำที่สงบ

นี่คือเอกสาร Laravel เกี่ยวกับเรื่องนี้

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.