'C' ใน MVC จำเป็นจริงๆหรือ

37

ฉันเข้าใจบทบาทของโมเดลและมุมมองในรูปแบบ Model-View-Controller แต่ฉันเข้าใจยากว่าเพราะเหตุใดคอนโทรลเลอร์จึงจำเป็น

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

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

design-patterns mvc

— Anne Nonimus
แหล่งที่มา

1

ส่วนตัวนี้คือสิ่งที่ผมทำ อาจมีบางกรณีที่ไม่มีทางเลือกอื่นสำหรับ MVC แต่ฉันทนไม่ได้

— Mike Dunlavey

10

คำสามคำ ... "การแยกความกังวล"

— Travis J

4

เกือบทุกโปรแกรม Windows ก่อน. net ใช้ Doc-View โดยไม่มีคอนโทรลเลอร์ ดูเหมือนว่าจะประสบความสำเร็จ

— Martin Beckett

Martin, un (เปลี่ยน) monolites ที่มีความสามารถ

— อิสระ

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

— คาเลบ

4

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

มีบางครั้งที่ผู้ควบคุมทั้งหมดทำคือส่งผ่านข้อมูลไปมาเช่นหน้าลงทะเบียน บางครั้งผู้ควบคุมเป็นส่วนที่ยากของการพัฒนาเพราะมีหลายสิ่งที่ต้องทำในชั้นนั้นเช่นการบังคับใช้กฎหรือทำคณิตศาสตร์ที่ซับซ้อนเช่น อย่าลืมคอนโทรลเลอร์!

— JustinDoesWork
แหล่งที่มา

36

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

— Dime

6

@Dime - ตัวแบบไม่ควรมีเหตุผลใด ๆ คอนโทรลเลอร์จะเป็นหนึ่งในตรรกะการถือครองดังนั้น "การควบคุม"

— Travis J

34

@TravisJ ไม่ค่อยเห็นด้วย การควบคุมไม่ได้หมายถึงการรู้วิธีการทำงาน มันเกี่ยวกับการควบคุมวัตถุเหล่านั้นที่ทำ ดังนั้นตรรกะสำหรับการทำงานจะอยู่ในรูปแบบและตัวควบคุมจะควบคุมรูปแบบที่จะใช้ในการปฏิบัติตามข้อกำหนดที่จำเป็นของการกระทำ ฯลฯ ตรรกะมากเกินไปในตัวควบคุมในมุมมองของฉันจะเป็นสูตรสำหรับตัวควบคุม blot ...

— dreza

25

จุดรวมของ OOP คือการรวบรวมข้อมูลและพฤติกรรมที่เหนียวแน่นไว้ด้วยกัน "Model" เป็นแบบจำลองพฤติกรรมและข้อมูล

— Misko

12

-1 ตัวควบคุมต้องไม่มีตรรกะทางธุรกิจ รูปแบบคือ "แอพ" มันเก็บข้อมูลและมีกิจวัตร callable สำหรับทุกสิ่งที่อาจเกิดขึ้นในแอพ; ไม่จำเป็นต้องมีทั้งหมดในไฟล์เดียวหรือคลาส มุมมองมองเห็นสถานะของโมเดล คอนโทรลเลอร์จะเชื่อมโยงโมเดล / มุมมองและโลกแห่งความเป็นจริง / อินพุต ต้องการ "เผยแพร่" แอปเป็นเว็บแอปหรือไม่ เพียงแค่ต้องใช้ตัวควบคุมที่จัดการ HTTP และมุมมองแบบ HTML ที่เหมาะสม ต้องการอินเตอร์เฟสบรรทัดคำสั่งสำหรับแอปของคุณหรือไม่ เพียงแค่ต้องมีตัวควบคุมและมุมมองที่เหมาะสม รูปแบบตรรกะทางธุรกิจไม่เคยเปลี่ยนแปลงในกรณีเหล่านี้

— หลอกลวง

39

ทำไมไม่เพียงทำทุกตรรกะบนตัวแบบในมุมมองของตัวเอง?

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

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

ดูสิ่งที่คุณได้รับจากการรักษาแบบจำลองและดูแยก:

คุณสามารถเปลี่ยนรุ่นหรือมุมมองได้โดยไม่ต้องเปลี่ยนรุ่นอื่น คุณอาจต้องอัปเดตคอนโทรลเลอร์เมื่อคุณเปลี่ยนอย่างใดอย่างหนึ่ง แต่ด้วยวิธีนี้เป็นส่วนหนึ่งของข้อได้เปรียบ: ส่วนต่าง ๆ ของโปรแกรมที่มีแนวโน้มที่จะเปลี่ยนแปลงจะเข้มข้นในคอนโทรลเลอร์
ทั้งโมเดลและมุมมองสามารถนำมาใช้ซ้ำได้ ตัวอย่างเช่นคุณสามารถใช้มุมมองกระดานหมากรุกเดียวกันกับตัวดึงข้อมูล RSS เป็นแบบจำลองเพื่ออธิบายเกมที่มีชื่อเสียง หรือคุณสามารถใช้โมเดลเดียวกันและแทนที่มุมมองด้วยอินเตอร์เฟสบนเว็บ
ง่ายในการเขียนการทดสอบสำหรับทั้งโมเดลและมุมมองเพื่อให้แน่ใจว่าทำงานได้อย่างที่ควรจะเป็น
ทั้งโมเดลและมุมมองสามารถใช้ประโยชน์จากชิ้นส่วนมาตรฐานได้บ่อยครั้ง: อาร์เรย์, แผนที่, ชุด, สตริง, และคอนเทนเนอร์ข้อมูลอื่น ๆ สำหรับโมเดล ปุ่มตัวควบคุมฟิลด์ข้อความมุมมองรูปภาพตารางและอื่น ๆ สำหรับมุมมอง

— คาเลบ
แหล่งที่มา

1

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

— kevin cline

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

— Dunk

2

@Dunk: มันมีความสำคัญต่อการแยกตรรกะทางธุรกิจออกจากส่วนติดต่อผู้ใช้เพื่อให้ตรรกะทางธุรกิจสามารถทดสอบได้โดยตรง

— kevin cline

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

— Dunk

1

@Dunk: ฉันคิดว่าคุณสามารถเรียกอะไรก็ได้ที่คุณชอบ "คอนโทรลเลอร์" แต่ในสถาปัตยกรรม MVC คอนโทรลเลอร์นั้นขึ้นอยู่กับดังนั้นจึงเป็นส่วนหนึ่งของส่วนต่อประสานผู้ใช้

— วินไคลน์

7

มีหลายวิธีที่แตกต่างกันของการใช้รูปแบบการออกแบบทั่วไปนี้ แต่แนวคิดพื้นฐานคือการแยกข้อกังวลต่าง ๆ ตามความจำเป็น MVC เป็นนามธรรมที่ดีในแง่ที่:

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

มีความยืดหยุ่นสูงเพราะไม่ได้ระบุจำนวนมาก ผู้คนมากมายเสียแบนด์วิดท์จำนวนมากเถียงรายละเอียดว่าแต่ละองค์ประกอบอาจหมายถึงอะไรควรใช้ชื่ออะไรแทนสิ่งเหล่านี้และควรจะมีส่วนประกอบ 3 หรือ 2 หรือ 4 หรือ 5 แต่ไม่มีจุดที่ ระดับหนึ่ง

ความคิดคือการแยก "chunks" ที่แตกต่างกันของตรรกะเพื่อที่จะไม่ทับซ้อนกัน รวบรวมข้อมูลการนำเสนอของคุณไว้ด้วยกันเก็บข้อมูลของคุณไว้ด้วยกันรวบรวมข้อมูลเชิงตรรกะของคุณเข้าด้วยกันรวบรวมข้อมูลการสื่อสารของคุณไว้ด้วยกัน และอื่น ๆ ในระดับหนึ่งขอบเขตของความกังวลน้อยกว่าเหล่านี้ทับซ้อนกันได้ง่ายขึ้นก็คือการทำสิ่งที่น่าสนใจกับพวกเขา

นั่นคือทั้งหมดที่คุณควรกังวลเกี่ยวกับ

— tylerl
แหล่งที่มา

3

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

— ZJR

1

+1 สำหรับ“ กาว”; มันก็หมายความว่ามันเป็นส่วนที่เหมาะสมที่สุดที่จะทำในภาษาสคริปต์ (ตามที่มักจะเก่งในการติดกาว)

— Donal Fellows

@ DonalFellows ฉันชอบความคิดนั้นมาก สิ่งที่ "glues" 2 หน่วยงานที่แตกต่างกันนั้นต้องการความยืดหยุ่นอย่างมากซึ่งภาษาสคริปต์ที่พิมพ์ออกมาอย่างอ่อน (เช่น JavaScript) จะได้รับการโปรโมต

— Zack Macomber

4

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

ฉันถูกถามว่าสามารถย้ายส่วนหมากรุก (มุมมอง) ไปยัง x ได้หรือไม่ มันจะ
ได้รับอนุญาต? ฉันไม่แน่ใจ แต่ฉันรู้ว่าจะถามใครและใคร (รุ่น)
มีบางอย่างขอให้ฉันบันทึกข้อมูลของฉัน ฉันจะทำยังไงได้ ฉันรู้ว่าต้องถามที่ไหน! วิธีที่เราบันทึกข้อมูลหรือที่ที่มันถูกบันทึกไปฉันไม่รู้เลย แต่คลาส Repository นั้นควรรู้ ฉันจะส่งต่อและให้มันจัดการกับมัน
ฉันต้องแสดงตำแหน่งหมากรุกปัจจุบันให้กับผู้ใช้ที่โมเดลย้ายไป ไม่แน่ใจว่าฉันต้องการที่จะแสดงชิ้นส่วนเป็นสีเขียวหรือสีเหลือง? Bah ใครสนใจฉันรู้ว่ามีมุมมองที่สามารถจัดการกับสิ่งนี้ได้ดังนั้นฉันจะส่งผ่านข้อมูลและพวกเขาสามารถตัดสินใจได้ว่าจะแสดงอย่างไร

ตัวอย่างเล็ก ๆ น้อย ๆ เหล่านี้เป็นตัวอย่างของวิธีที่ฉันพยายามจดจำสิ่งที่เป็นนามธรรมและแนวคิด MVC กำลังพยายามสื่อความหมาย อะไรที่ไหนและอย่างไรกระบวนการคิดหลักสามประการของฉันคืออะไร

อะไรและที่ไหน => ตัวควบคุมอย่างไรและเมื่อใด => แบบจำลองและมุมมอง

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

— dreza
แหล่งที่มา

2

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

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

— hotpaw2
แหล่งที่มา

2

มันเข้ามามีบทบาทจริงๆเมื่อคุณจัดการกับตัวจัดการเหตุการณ์ แต่คุณยังต้องการคอนโทรลเลอร์เพื่อจัดการการโต้ตอบระหว่างมุมมองและโมเดล เป็นการดีที่คุณไม่ต้องการให้มุมมองรู้อะไรเกี่ยวกับโมเดล ลองคิดดูคุณต้องการให้ jsp โทรฐานข้อมูลทั้งหมดโดยตรงหรือไม่ (นอกเสียจากว่าจะเป็นสิ่งที่ค้นหาในการเข้าสู่ระบบ) คุณต้องการให้มุมมองแสดงข้อมูลและไม่มีตรรกะทางธุรกิจใด ๆ เว้นแต่ว่าจะเป็นมุมมองการแสดงผลเชิงตรรกะ แต่ไม่ใช่ perse เชิงตรรกะทางธุรกิจ

ใน GWT คุณจะได้รับการแยกที่สะอาดขึ้นด้วย MVP ไม่มีตรรกะทางธุรกิจใด ๆ (ถ้าทำได้ถูกต้อง) ในมุมมอง ผู้นำเสนอทำหน้าที่เป็นตัวควบคุมและมุมมองไม่มีความรู้เกี่ยวกับโมเดล ข้อมูลโมเดลถูกส่งผ่านไปยังมุมมอง

1

มุมมองเอกสาร (เช่นมุมมองแบบจำลอง) เป็นแบบจำลองมาตรฐานสำหรับแอพ Windows ส่วนใหญ่ที่เขียนด้วย MFC ดังนั้นจึงต้องใช้งานได้หลายกรณี

— Martin Beckett
แหล่งที่มา

1

ฉันเข้าใจบทบาทของโมเดลและมุมมองในรูปแบบ Model-View-Controller แต่ฉันเข้าใจยากว่าเพราะเหตุใดคอนโทรลเลอร์จึงจำเป็น

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

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

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

— stonemetal
แหล่งที่มา

0

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

IMO ควรมี API (แบ็กเอนด์) และแอพที่ใช้ API (ส่วนหน้า) ฉันเดาว่าคุณสามารถโทรขอ GET ตัวควบคุม (ซึ่งเรียกง่ายๆว่าแบ็กเอนด์ api) และมุมมอง html แต่โดยปกติฉันไม่ได้ยินคนพูดถึงมุมมองว่าเป็น html บริสุทธิ์หรือแบบจำลองเป็น API แบ็กเอนด์

IMO ทุกอย่างควรเป็น API ที่มั่นคง ที่จริงแล้วพวกเขาไม่จำเป็นต้องมีความมั่นคง (เช่นในความสะอาดและสร้างขึ้นอย่างดี) แต่ภายในควรเป็นแบบส่วนตัวและแอพ / ส่วนหน้า / ด้านนอกของ api ไม่ควรได้รับการพูดว่าการเชื่อมต่อฐานข้อมูล

ตอนนี้ถ้ารหัส / การออกแบบของคุณเกี่ยวข้องกับกาว หากในเกมหมากรุกของคุณมีมาร์กอัปบางอย่างคุณสามารถแก้ไขเพื่อ GUI สกิน GUI จะรวบรวม coords / input และเรียกใช้ MovePiece (srcPosition, dstPostion) (ซึ่งอาจส่งคืน bool หรือ enum เพื่อบอกว่าเป็นการย้ายที่ถูกต้องหรือไม่ ) และคุณตกลงกับตรรกะทั้งหมดที่อยู่ในรูปแบบแล้วโปรดเรียกว่า MVC อย่างไรก็ตามฉันยังคงจัดระเบียบสิ่งต่าง ๆ ตามคลาสและ API และตรวจสอบให้แน่ใจว่าไม่มีคลาสอ่างล้างจานที่สัมผัสทุกอย่าง (หรือ API ใด ๆ ที่ต้องรู้เกี่ยวกับทุกสิ่ง)

คุณยินดีรับฟังความคิดเห็นของคุณ แต่คำตอบนี้ไม่ได้พยายามตอบคำถามของ OP

— Caleb

0

คิดว่าเบราว์เซอร์ที่แสดงหน้าเว็บแบบคงที่ รูปแบบคือ HTML มุมมองเป็นผลลัพธ์จริงบนหน้าจอ

ตอนนี้เพิ่ม JavaScript บางส่วน นั่นคือตัวควบคุม เมื่อผู้ใช้คลิกที่ปุ่มหรือลากสิ่งที่กิจกรรมถูกส่งไปยัง JavaScript จะทำการตัดสินใจว่าจะทำอย่างไรและเปลี่ยนแปลง HTML พื้นฐาน (รุ่น) และเบราว์เซอร์ / ตัวแสดงผลจะแสดงการเปลี่ยนแปลงเหล่านั้นบนหน้าจอ (มุมมอง)

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

คอนโทรลเลอร์ตอบสนองต่อเหตุการณ์และควบคุมสิ่งที่อยู่ในรูปแบบและสิ่งที่อยู่บนหน้าจอ / มุมมอง

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

ลงในเซิร์ฟเวอร์ไม่ว่าจะเป็น asp, php หรือ java 'code' (Controller) จะได้รับเหตุการณ์การคลิกและทำการสืบค้นฐานข้อมูลหรือที่เก็บเอกสาร (Model) และสร้าง HTML จากมุมมองเซิร์ฟเวอร์ผลลัพธ์ของการกระทำทั้งหมดคือมุมมอง (HTML) ของที่เก็บข้อมูลพื้นฐาน (รุ่น) แต่จากมุมมองของลูกค้าผลลัพธ์ของการร้องขอไปยังเซิร์ฟเวอร์คือ Model (HTML)

แม้ว่าคุณจะสับสนจาวาสคริปต์ใน HTML หรือ PHP ในรูปแบบ HTML, View, Controller ก็ยังคงอยู่ แม้ว่าคุณคิดว่าคำขอของคุณไปยังเซิร์ฟเวอร์และการตอบกลับจากเซิร์ฟเวอร์เป็นถนนสองทางแบบง่าย ๆ ก็ยังมีรูปแบบมุมมองและตัวควบคุม

— ซุส
แหล่งที่มา

-2

จากประสบการณ์ของฉันในโปรแกรม mvc gui แบบเดสก์ท็อปคอนโทรลเลอร์จะสิ้นสุดลงในมุมมอง คนส่วนใหญ่ไม่ใช้เวลาในการแยกชั้นควบคุม

หนังสือแก๊งสี่กล่าวว่า:

รูปแบบการออกแบบใน Smalltalk MVC

Model / View / Controller (MVC) สามชั้นของคลาส [KP88] ใช้เพื่อสร้างส่วนต่อประสานกับผู้ใช้ใน Smalltalk-80 การดูรูปแบบการออกแบบภายใน MVC จะช่วยให้คุณเห็นความหมายของคำว่า "รูปแบบ"

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

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

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

ตัวอย่างนี้สะท้อนถึงการออกแบบที่แยกแยะมุมมองจากโมเดล แต่การออกแบบนั้นสามารถใช้ได้กับปัญหาทั่วไปที่มากกว่า: การแยกวัตถุออกเพื่อให้การเปลี่ยนแปลงหนึ่งสามารถส่งผลกระทบต่อจำนวนของคนอื่น ๆ โดยไม่ต้องให้วัตถุที่ถูกเปลี่ยนไปรู้รายละเอียดของคนอื่น การออกแบบทั่วไปนี้อธิบายโดยรูปแบบการออกแบบของ Observer (หน้า 293)

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

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

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

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

ความสัมพันธ์ View-Controller เป็นตัวอย่างของรูปแบบการออกแบบ Strategy (315) กลยุทธ์เป็นวัตถุที่แสดงถึงอัลกอริทึม มันมีประโยชน์เมื่อคุณต้องการแทนที่อัลกอริทึมทั้งแบบคงที่หรือแบบไดนามิกเมื่อคุณมีความหลากหลายของอัลกอริทึมหรือเมื่ออัลกอริทึมมีโครงสร้างข้อมูลที่ซับซ้อนที่คุณต้องการแค็ปซูล

MVC ใช้รูปแบบการออกแบบอื่น ๆ เช่นวิธีโรงงาน (107) เพื่อระบุคลาสตัวควบคุมเริ่มต้นสำหรับมุมมองและตัวตกแต่ง (175) เพื่อเพิ่มการเลื่อนไปยังมุมมอง แต่ความสัมพันธ์หลักใน MVC นั้นมาจากรูปแบบการออกแบบของผู้สังเกตการณ์คอมโพสิตและกลยุทธ์

— Ray Tayek
แหล่งที่มา

1

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

— คาเลบ

1

ฉันต้องไม่เห็นด้วยกับความคิดเห็นของคุณว่า "ตัวควบคุมกลายเป็นสปาเก็ตตี้ในมุมมอง" บางทีมันอาจแตกต่างกันไปตามแพลตฟอร์มและกรอบงานที่คุณใช้ แต่มันเป็นเรื่องธรรมดามากในการเขียนโปรแกรม Cocoa และ Cocoa Touch เพื่อสร้างตัวควบคุมที่เหมาะสมมากกว่าที่จะละเว้น ถ้าโปรแกรมเมอร์ Objective-C ละเว้นหมวดหมู่ใดหมวดหมู่หนึ่งมันเกือบจะแน่นอนว่าเป็นรุ่นที่ทนทุกข์ทรมาน

— คาเลบ

หากคุณยอมรับว่านี่เป็นการตีความ "เหมาะสม" ของ MVC MVC จะไม่ซื้ออะไรเลย มันอาจเป็นเพียง MV และเลิกใช้ C เพราะทุกครั้งที่คุณสร้างมุมมองใหม่คุณยังต้องสร้างคอนโทรลเลอร์ใหม่ อะไรคือจุดที่ทำให้ปวดแยกพวกเขานอกเหนือจากเหตุผลทางทฤษฎีของการแยกความกังวล

— Dunk