การปรับปรุง MVP ผ่าน MVC คืออะไร

ฉันได้อ่านสามวันเกี่ยวกับModel-View-Controller (MVC)และModel-View-Presenter (MVP)รูปแบบ และมีคำถามหนึ่งที่รบกวนจิตใจฉันอย่างมาก ทำไมนักออกแบบซอฟต์แวร์จึงคิดค้น MVP เมื่อมี MVC อยู่แล้ว

พวกเขาประสบปัญหาอะไรบ้าง MVC ไม่ได้แก้ปัญหา (หรือแก้ไขไม่ดี) แต่ MVP สามารถแก้ไขได้ MVP ปัญหาใดที่ตั้งใจจะแก้ไข?

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

ในหนึ่งในบทความที่ฉันอ่านมันก็บอกว่า:

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

ดังนั้นฉันจึงไม่เข้าใจ แต่จริง ๆ แล้วมันสามารถเป็นไปได้ในทางอื่นเช่นองค์ประกอบ GUI ไม่จัดการกับการป้อนข้อมูลของผู้ใช้ด้วยตัวเอง? และ "จัดการกับตัวเอง" หมายความว่าอย่างไร?

MVC มีแนวคิดที่สง่างาม:

• อินพุตของผู้ใช้ถูกจัดการโดยคอนโทรลเลอร์
• คอนโทรลเลอร์จะอัพเดตโมเดล
• โมเดลจะอัพเดตมุมมอง / ส่วนต่อประสานผู้ใช้

           +---+
      +----| V |<----+
user  |    +---+     | updates
input |              |
      v              |
    +---+          +---+
    | C |--------->| M |
    +---+ updates  +---+

อย่างไรก็ตาม: ข้อมูลและการไหลของเหตุการณ์ใน MVC เป็นแบบวงกลม และมุมมองมักจะมีตรรกะที่สำคัญ (เช่นตัวจัดการเหตุการณ์สำหรับการกระทำของผู้ใช้) คุณสมบัติเหล่านี้ทำให้ระบบทดสอบและบำรุงรักษายาก

สถาปัตยกรรม MVP แทนที่ตัวควบคุมด้วยผู้นำเสนอซึ่งเป็นสื่อกลางระหว่างมุมมองและรูปแบบ ทำให้ระบบเป็นเส้นตรง:

       user input         updates
+---+ -----------> +---+ --------> +---+
| V |              | P |           | M |
+---+ <----------- +---+ <-------- +---+
        updates            updates

นี่มีข้อดีดังต่อไปนี้:

• ลอจิก (เช่นตัวจัดการเหตุการณ์และสถานะส่วนต่อประสานผู้ใช้) สามารถย้ายจากมุมมองไปยังผู้นำเสนอ

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

• เนื่องจากส่วนต่อประสานผู้ใช้ถูกแยกออกจากตรรกะของแอปพลิเคชันทั้งคู่จึงสามารถพัฒนาได้อย่างอิสระ

แต่ก็มีข้อเสียบางอย่างสำหรับวิธีการนี้:

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

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