ใน MVC อะไรคือความแตกต่างระหว่างคอนโทรลเลอร์และเราเตอร์


19

พวกเขาหมายถึงสิ่งเดียวกัน (แนบ URL กับการกระทำหรือการกระทำกับ URL) หรือมีความแตกต่างที่ฉันขาดหายไปหรือไม่?

ตัวอย่าง: http://github.com/dannyvankooten/PHP-Router vs. http://konstrukt.dk


1
เราเตอร์นั้นฟังดูเหมือนพร็อกซี่ที่เชิดชูฉันมากกว่า
วงล้อประหลาด

คุณต้องการโมเดล (ฐานข้อมูล) ตัวควบคุม (ซึ่งเป็นเราเตอร์) และมุมมอง (หน้า) แค่นั้นแหละ. หากคุณมีเราเตอร์และคอนโทรลเลอร์คุณก็ซับซ้อนเกินกว่าจะเป็นเพียงแค่ใช้เราเตอร์เพื่อส่งข้อมูลไปยังคอนโทรลเลอร์ คอนโทรลเลอร์เป็นเราท์เตอร์ แต่เราเตอร์ไม่ใช่คอนโทรลเลอร์ ดูที่นี่code.tutsplus.com/tutorials/mvc-for-noobs--net-10488
ฉบับที่

คำตอบ:


15

Router:

การกำหนดเส้นทางเป็นกระบวนการรับปลายทาง URI (ส่วนหนึ่งของ URI ซึ่งมาหลังจาก URL พื้นฐาน) และแยกย่อยเป็นพารามิเตอร์เพื่อพิจารณาว่าโมดูลตัวควบคุมและการกระทำใดของตัวควบคุมนั้นควรได้รับการร้องขอ

ควบคุม:

คอนโทรลเลอร์ใช้รูปแบบตัวควบคุมซึ่งคำขอทั้งหมดจะถูกสกัดกั้นโดยตัวควบคุมและส่งไปยังตัวควบคุมแต่ละตัวตาม URL ที่ร้องขอ (นั่นคือคำขอเส้นทางจากเราเตอร์)


4

Frontend-ควบคุมควรจะทำงานร่วมกันกับเราท์เตอร์และรีบที่จะตัดสินใจบนพื้นฐานของคำขอ (HTTP)กับแอพลิเคชันที่เป็นรูปธรรมการดำเนินการจะต้องมีการดำเนินการแล้วยื้อมัน

ขึ้นอยู่กับว่ารายละเอียดของการออกแบบที่เป็นบางส่วนควบคุมของการทำงานโดยไม่ต้องRouter sและพวกเขาไม่เส้นทางของตัวเองหรือเส้นทางเป็นนัยในการออกแบบวิธีการร้องขอการประมวลผล

บางคนรีบ sยังผ่านการขอวัตถุที่จะส่งวิธีการดำเนินการ วิธีการดำเนินการจากนั้นย่อยสลายคำร้องขอในส่วนเพื่อให้แม้แต่การกระทำของตัวควบคุมยังสามารถทำเส้นทางบางอย่างตามคำขอ ตัวอย่างทั่วไปสำหรับกรณีนี้คือเมื่อกรอบเสนอให้ทำการเปลี่ยนเส้นทางเป็นการตอบสนอง สิ่งนี้ยังแสดงให้เห็นว่าเกี่ยวข้องหรือใกล้กับเราเตอร์และคอนโทรลเลอร์อย่างไร

ความแตกต่างที่มักจะวาดที่นี่คือการกำหนดเส้นทางจะดูแลหรือช่วยในการระบุวิธีการดำเนินการที่จะดำเนินการและตัวควบคุมนั้นมีหน้าที่รับผิดชอบในการให้การกระทำนี้ แต่ทั้งสองจัดการคำขอ

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

อย่างไรก็ตามจากคำที่ฉันบอกว่าControllerอยู่ในบทบาทที่สูงขึ้นในแอปพลิเคชันโดยรวม นี่คือสิ่งที่การกระทำจะพูด


3

เส้นทางจะจับคู่ URL กับตัวควบคุมซึ่งเป็นการกระทำ บางครั้งบทบาทไม่ได้แยกออกจากกันได้ดีมากขึ้นอยู่กับกรอบ


2

เราเตอร์เป็นส่วนหนึ่งของชั้นควบคุม กลไกการประมวลผลเราเตอร์คือการเปลี่ยนรูปแบบ Front Controller โรงเรียนเก่า (สวิตช์ขนาดใหญ่ใน index.php)

ในกรอบการทำงานสมัยใหม่เราเตอร์จะกำหนดการเชื่อมต่อโดยตรงระหว่าง "ชนิด" ของคำขอที่เป็นไปได้และตัวประมวลผล ในทางตรงกันข้ามผู้ควบคุมจะได้รับการระบุข้อมูลและแยกวิเคราะห์ข้อมูลในบริบทของตัวเอง


0

ค่อนข้างง่ายเราเตอร์ทำงานออกเดินทางผ่านแอปพลิเคชันมักจะขึ้นอยู่กับปัจจัยภายนอกเช่นตัวแปร GET หรือ POST

เราเตอร์ไม่ได้เป็นส่วนหนึ่งของ MVC ใด ๆ เฟรมเวิร์ก MVC และ HMVC จำนวนมากใช้เราเตอร์ แต่สิ่งนี้ไม่ได้ผูกกับรูปแบบของ MVC

นอกจากนี้การใช้ MVC ก่อนหน้านี้ฉันได้เห็นการพึ่งพาการแยกไฟล์ตามการกระทำด้วยไฟล์หนึ่งไฟล์ต่อคอนโทรลเลอร์สำหรับการเข้าถึงคอนโทรลเลอร์ที่แยกต่างหาก สิ่งนี้ให้บริการแอปพลิเคชันได้ดีกว่ามากเนื่องจากการมีตัวควบคุมแบบผอมและแบบจำลองที่แข็งแกร่งกว่าเดิมคุณไม่จำเป็นต้องเลื่อนไปที่วิธีการเฉพาะในคอนโทรลเลอร์และดังนั้นคุณจึงสามารถเข้าถึงตรรกะได้ในที่เดียว (แบบจำลอง) พฤติกรรม


-1

เราเตอร์เตะ

ขอร้อง

และตัดสินใจว่าวิธีการควบคุม / ตัวควบคุมใดจะจัดการการร้องขอ

คอนโทรลเลอร์รับคำขอและจัดการมัน!

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

นี่ไม่ใช่ตัวควบคุม (เท่าที่เกี่ยวข้องกับ MVC) มันเป็นส่วนหนึ่งของเส้นทาง

ตัวอย่างเช่นใช้ [GET] uri: example.com/article/view/123 เราเตอร์ MVC จะแยกวิเคราะห์ uri และค้นหาเซ็กเมนต์ต่อไปนี้

มุมมองบทความ 123 โดยค่าเริ่มต้นเราเตอร์ส่วนใหญ่ตอนนี้จะยกตัวอย่าง ArticleController และเรียกวิธีการดูผ่านใน 123 เป็นพารามิเตอร์ (หรือคุณอาจมีวิธี getUriSegment (segmentIdx) ซึ่งเป็นตัวเลือกการออกแบบสำหรับกรอบงานของคุณ)

ArticleController จะมีวิธีการดูด้วยพารามิเตอร์ $ articleId วิธีนี้อาจจะทำสิ่งที่ชอบ: รับบทความที่ระบุ (จาก db ผ่านแบบจำลองตัวอย่าง) แล้วแสดงมัน (อาจโดยการส่งคืนมุมมองที่ได้รับบทความที่ส่งคืนโดยแบบจำลอง

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