MVP และ MVC คืออะไรและแตกต่างกันอย่างไร

2133

เมื่อมองไปไกลกว่าRAD (ลากวางและกำหนดค่า) วิธีการสร้างส่วนติดต่อผู้ใช้ที่เครื่องมือมากมายขอแนะนำให้คุณมีแนวโน้มที่จะเจอสามรูปแบบการออกแบบที่เรียกว่าModel-View-Controller , Model-View-PresenterและModel-View-ViewModel คำถามของฉันมีสามส่วน:

รูปแบบเหล่านี้แก้ไขปัญหาใด
พวกเขาคล้ายกันอย่างไร
แตกต่างกันอย่างไร

— Mike Minutillo
แหล่งที่มา

4

mvc.givan.se/#mvp

— givanse

2

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

— still_dreaming_1

MVP เพิ่มเลเยอร์ทางอ้อมเป็นพิเศษโดยแยก View-Controller เป็น View และ Presenter ...

— the_prole

2

ข้อแตกต่างที่สำคัญคือใน MVC คอนโทรลเลอร์ไม่ส่งผ่านข้อมูลใด ๆ จากแบบจำลองไปยังมุมมอง มันแค่แจ้งมุมมองเพื่อรับข้อมูลจากตัวโมเดลเอง อย่างไรก็ตามใน MVP ไม่มีการเชื่อมต่อระหว่าง View และ Model ผู้นำเสนอเองได้รับข้อมูลใด ๆ ที่จำเป็นจากแบบจำลองและส่งต่อไปยังมุมมองเพื่อแสดง สิ่งนี้เพิ่มเติมพร้อมกับตัวอย่าง android ในรูปแบบสถาปัตยกรรมทั้งหมดอยู่ที่นี่: digigene.com/category/android/android-architecture

— Ali Nem

พวกเขาจะเรียกรูปแบบสถาปัตยกรรมที่ไม่ได้ออกแบบรูปแบบ หากคุณต้องการทราบความแตกต่างโปรดตรวจสอบสิ่งนี้

— Hasan El-Hefnawy

1997

Model-View-Presenter

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

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

สองรูปแบบหลัก

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

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

Supervising Controller: The Presenter จัดการท่าทางผู้ใช้ มุมมองผูกกับโมเดลโดยตรงผ่านการเชื่อมโยงข้อมูล ในกรณีนี้เป็นหน้าที่ของผู้นำเสนอในการส่งต่อโมเดลไปยังมุมมองเพื่อให้สามารถเชื่อมโยงกับโมเดลได้ ผู้นำเสนอจะมีตรรกะสำหรับท่าทางเช่นการกดปุ่มการนำทางและอื่น ๆ

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

Model-View-Controller

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

    การดำเนินการในมุมมอง
        -> Call to Controller
        -> ลอจิกตัวควบคุม
        -> Controller ส่งคืนมุมมอง

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

รูปแบบการนำเสนอ

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

มีบทความเกี่ยวกับ MSDN เกี่ยวกับรูปแบบการนำเสนอและส่วนในComposite Application Guidance สำหรับ WPF (ปริซึมเดิม) เกี่ยวกับรูปแบบการนำเสนอที่แยกจากกัน

— Glenn Block
แหล่งที่มา

27

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

— Panzercrisis

16

@Panercrisis ฉันไม่แน่ใจว่านี่คือสิ่งที่ผู้เขียนต้องการหรือไม่ แต่นี่คือสิ่งที่ฉันคิดว่าพวกเขากำลังพยายามจะพูด เช่นเดียวกับคำตอบนี้ - stackoverflow.com/a/2068/74556กล่าวถึงใน MVC วิธีการควบคุมขึ้นอยู่กับพฤติกรรม - กล่าวอีกนัยหนึ่งคุณสามารถแมปมุมมองหลายมุมมอง (แต่ลักษณะการทำงานเดียวกัน) กับตัวควบคุมเดียว ใน MVP ผู้นำเสนอจะอยู่ใกล้กับมุมมองมากขึ้นและมักส่งผลให้มีการแมปที่ใกล้เคียงกับแบบหนึ่งต่อหนึ่งเช่นมุมมองแอ็คชันจะแมปกับวิธีของผู้นำเสนอที่สอดคล้องกัน โดยทั่วไปคุณจะไม่แมปการกระทำของมุมมองอื่นกับวิธีการของผู้นำเสนอคนอื่น (จากมุมมองอื่น)

— ดัสตินเคนดัลล์

2

โปรดทราบว่า MVCมักใช้งานโดยเว็บเฟรมเวิร์กเช่นLaravelที่ซึ่งคำขอ URL ที่ได้รับ (อาจทำโดยผู้ใช้) ได้รับการจัดการโดยControllerและ HTML ที่สร้างโดยViewถูกส่งไปยังไคลเอนต์ - ดังนั้นจึงViewเป็นส่วนหนึ่งของแบ็กเอนด์และ ผู้ใช้ไม่สามารถเข้าถึงได้โดยตรงและหากคุณพบที่ใดก็ตามตรงกันข้ามให้ถือว่าเป็นส่วนขยาย MVC (หรือแม้แต่การละเมิด) @Panzercrisis แตกต่างจากนี้MVP(เช่นเดียวกับที่ใช้ในAndroidOS) ที่ผู้ใช้และมีการเข้าถึงโดยตรงไปยังactions route through the View to the Presenter View

— สุดยอดอาจารย์

455

นี่เป็นการอธิบายแบบที่หลากหลายของรูปแบบการออกแบบเหล่านี้ แต่นี่เป็นวิธีที่ฉันคิดเกี่ยวกับความแตกต่างระหว่างสองแบบนี้

MVC

MVC

MVP

ป้อนคำอธิบายรูปภาพที่นี่

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

10

นี่เป็นภาพที่ยอดเยี่ยมของแผนผังแสดงการแยกและการแยก GUI ใด ๆ ที่เกี่ยวข้อง (ดูเนื้อหา) จาก API ของผู้นำเสนออย่างสมบูรณ์ จุดเล็ก ๆ จุดหนึ่ง: ผู้นำเสนอหลักสามารถใช้ในที่ที่มีผู้นำเสนอเพียงคนเดียวมากกว่าหนึ่งคนต่อการดู แต่แผนภาพของคุณนั้นสะอาดที่สุด IMO ความแตกต่างที่ใหญ่ที่สุดระหว่าง MVC / MVP คือ MVP พยายามที่จะรักษามุมมองให้เป็นโมฆะโดยสิ้นเชิงจากสิ่งอื่นนอกจากการแสดงสถานะ 'มุมมอง' ปัจจุบัน (ดูข้อมูล) ในขณะที่ไม่อนุญาตให้ดูความรู้เกี่ยวกับวัตถุโมเดล ดังนั้นอินเทอร์เฟซที่จำเป็นต้องมีเพื่อฉีดสถานะนั้น

4

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

— splungebob

3

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

— Samuel A. Falvo II

3

@ SamuelA.FalvoII ไม่เสมอมี 1: ระหว่างตัวควบคุมและมุมมองใน ASP.NET MVC: stackoverflow.com/questions/1673301/ …

— StuperUser

4

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

— Samuel A. Falvo II

421

ฉัน blogged เกี่ยวกับเรื่องนี้ในขณะที่กลับมาอ้างถึงโพสต์ที่ยอดเยี่ยมของทอดด์สไนเดอเกี่ยวกับความแตกต่างระหว่างทั้งสอง :

นี่คือความแตกต่างที่สำคัญระหว่างรูปแบบ:

รูปแบบ MVP

มุมมองจะถูกรวมเข้ากับโมเดลอย่างอิสระมากขึ้น ผู้นำเสนอรับผิดชอบการเชื่อมโยงโมเดลเข้ากับมุมมอง

ทดสอบหน่วยได้ง่ายขึ้นเนื่องจากการโต้ตอบกับมุมมองผ่านส่วนต่อประสาน

มักจะดูเพื่อนำเสนอแผนที่หนึ่งต่อหนึ่ง มุมมองที่ซับซ้อนอาจมีผู้นำเสนอหลายคน

รูปแบบ MVC

ตัวควบคุมขึ้นอยู่กับพฤติกรรมและสามารถแชร์ข้ามมุมมองได้

สามารถรับผิดชอบในการกำหนดมุมมองที่จะแสดง

มันเป็นคำอธิบายที่ดีที่สุดในเว็บที่ฉันสามารถหาได้

— จอน Limjap
แหล่งที่มา

15

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

— Bill K

18

@pst: ด้วย MVP จริงๆแล้ว 1 View = 1 Presenter ด้วย MVC คอนโทรลเลอร์สามารถควบคุมหลายมุมมอง แค่นี้แหละ ด้วยรูปแบบ "แท็บ" ให้จินตนาการว่าแต่ละแท็บมีพรีเซนเตอร์ของตนเองซึ่งต่างจากการมีคอนโทรลเลอร์หนึ่งอันสำหรับแท็บทั้งหมด

— Jon Limjap

4

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

— Acsor

1

@JonLimjap มันหมายความว่าอย่างไรโดยหนึ่งมุมมองต่อไป? ในบริบทของการเขียนโปรแกรม iOS มันเป็นแบบหน้าจอเดียวหรือไม่? สิ่งนี้ทำให้คอนโทรลเลอร์ของ iOS เหมือน MVP มากกว่า MVC หรือไม่ (ในทางกลับกันคุณยังสามารถมีตัวควบคุม iOS ได้หลายตัวต่อหน้าจอ)

— ฮักกี้

2

ภาพประกอบจาก MVC ของโทดด์ขัดแย้งกับแนวคิดการแยกมุมมองและโมเดลออกมาอย่างสมบูรณ์ ถ้าคุณดูไดอะแกรมมันบอกว่า Model updates View (ลูกศรจาก Model to View) ในเอกภพใดเป็นระบบที่ตัวแบบโต้ตอบโดยตรงกับมุมมองซึ่งเป็นตัวแยก

— Ash

260

นี่คือภาพประกอบซึ่งแสดงถึงการไหลของการสื่อสาร

ป้อนคำอธิบายรูปภาพที่นี่

— Ashraf Bashir
แหล่งที่มา

44

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

— Brian Rizo

54

หากผู้ใช้คลิกปุ่มสิ่งนั้นจะไม่ทำงานกับมุมมองอย่างไร ฉันรู้สึกเหมือนใน MVC ผู้ใช้โต้ตอบกับมุมมองมากกว่าตัวควบคุม

— Jonathan

5

ฉันรู้ว่านี่เป็นคำตอบเก่า - แต่ทุกคนสามารถตอบกลับใน @JonathanLeaders ฉันมาจากพื้นหลัง winforms เว้นแต่ว่าคุณจะได้รหัสที่ไม่เหมือนใครเมื่อคุณคลิก UI / มุมมองจะได้รับความรู้เกี่ยวกับการคลิกนั้นก่อนสิ่งอื่นใด อย่างน้อยเท่าที่ฉันรู้?

— Rob P.

6

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

— Luca Fülbier

15

@JanathanLeaders ผู้คนมีความคิดที่แตกต่างกันจริงๆเมื่อพวกเขาพูดว่า "MVC" ผู้ที่สร้างแผนภูมินี้อาจมี Web MVC แบบคลาสสิกอยู่ในใจโดยที่ "การป้อนข้อมูลผู้ใช้" เป็นคำขอ HTTP และ "มุมมองที่ส่งคืนไปยังผู้ใช้" เป็นหน้า HTML ที่แสดงผล ดังนั้นการโต้ตอบใด ๆ ระหว่างผู้ใช้และมุมมองจึงเป็น "ไม่มีอยู่" จากมุมมองของผู้เขียนแอป Web MVC แบบคลาสสิก

— cubuspl42

170

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

พูดอย่างตรงไปตรงมาผมคิดว่าความกังวลพื้นฐานของ MVC ถือเป็นจริงสำหรับการใช้งาน MVP และความแตกต่างนั้นเกือบจะเป็นความหมายทั้งหมด ตราบใดที่คุณแยกความกังวลระหว่างมุมมอง (ที่แสดงข้อมูล) ตัวควบคุม (ที่เริ่มต้นและควบคุมการโต้ตอบกับผู้ใช้) และโมเดล (ข้อมูลพื้นฐานและ / หรือบริการ) จากนั้นคุณจะได้รับประโยชน์จาก MVC . หากคุณได้รับผลประโยชน์ผู้ที่ใส่ใจว่ารูปแบบของคุณคือ MVC, MVP หรือ Supervising Controller? รูปแบบที่แท้จริงเท่านั้นยังคงเป็น MVC ส่วนที่เหลือเป็นเพียงรสชาติที่แตกต่างกัน

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

โดยส่วนตัวฉันคิดว่า MVP เพิ่งถูกนำมาใช้ใหม่เป็นคำที่จับต้องไม่ได้เพื่อลดการขัดแย้งระหว่าง semantic bigots ที่อ้างว่าบางสิ่งบางอย่างเป็น MVC อย่างแท้จริงหรือไม่หรือเพื่อพิสูจน์เครื่องมือของ Microsoft Rapid Application Development เหตุผลเหล่านี้ในหนังสือของฉันไม่ได้ให้เหตุผลว่าทำไมรูปแบบการออกแบบจึงแยกกัน

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

28

ฉันได้อ่านคำตอบและบล็อกต่าง ๆ เกี่ยวกับความแตกต่างระหว่าง MVC / MVP / MVVM / etc ' ผลก็คือเมื่อคุณทำธุรกิจได้ทุกอย่างก็เหมือนกัน ไม่สำคัญว่าคุณจะมีอินเทอร์เฟซหรือไม่และคุณกำลังใช้เซทเทอร์ (หรือฟีเจอร์ภาษาอื่น ๆ ) ปรากฏว่าความแตกต่างระหว่างรูปแบบเหล่านี้เกิดจากความแตกต่างของการใช้งานกรอบต่าง ๆ มากกว่าเรื่องของแนวคิด

— Michael

6

ฉันจะไม่เรียก MVP ว่าเป็นรูปแบบการต่อต้านในภายหลังในโพสต์ ".. ส่วนที่เหลือ [รวมถึง MVP] เป็นเพียงรสชาติที่แตกต่างของ [MVC] .. " ซึ่งจะบอกเป็นนัยว่าหาก MVP เป็นรูปแบบต่อต้านดังนั้น MVC คือ ... มันเป็นเพียงรสชาติของแนวทางที่แตกต่าง (ตอนนี้การใช้งาน MVP บางอย่างอาจเป็นที่ต้องการมากกว่าหรือน้อยกว่าการใช้ MVC เฉพาะสำหรับงานที่แตกต่างกัน ... )

@Quibblsome:“ โดยส่วนตัวแล้วฉันคิดว่า MVP เพิ่งถูกนำมาใช้อีกครั้งเมื่อไม่นานมานี้เพื่อลดข้อโต้แย้งระหว่าง semantic bigots ที่เถียงว่า MVC อย่างแท้จริงหรือไม่ […] ทั้งสองเหตุผลเหล่านี้ในหนังสือของฉันแสดงให้เห็นว่า รูปแบบการออกแบบแยกต่างหาก” . มันแตกต่างกันมากพอที่จะทำให้มันชัดเจน ใน MVP มุมมองอาจเป็นอะไรก็ได้ที่ทำตามอินเตอร์เฟสที่กำหนดไว้ล่วงหน้า (มุมมองใน MVP เป็นองค์ประกอบแบบสแตนด์อโลน) ใน MVC คอนโทรลเลอร์สร้างขึ้นเพื่อมุมมองเฉพาะ (ถ้าความสัมพันธ์ของความสัมพันธ์อาจทำให้บางคนรู้สึกว่ามันคุ้มค่ากับคำอื่น)

— Hibou57

6

@ Hibou57 ไม่มีอะไรที่จะหยุด MVC จากการอ้างอิงมุมมองเป็นส่วนต่อประสานหรือสร้างตัวควบคุมทั่วไปสำหรับมุมมองที่แตกต่างกัน

— Quibblesome

1

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

— Quibblesome

110

MVP: มุมมองอยู่ในความดูแล

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

MVC: คอนโทรลเลอร์อยู่ในความดูแล

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

— Brian Leahy
แหล่งที่มา

3

"มุมมองไม่ทราบเกี่ยวกับตัวควบคุม" ฉันคิดว่าคุณหมายถึงว่ามุมมองนั้นไม่มีการติดต่อโดยตรงกับโมเดลใช่หรือไม่

— Lotus Notes

2

มุมมองที่ไม่ควรรู้เกี่ยวกับรูปแบบใน eiether หนึ่ง

— Brian Leahy

4

@Brian:“ มุมมองส่วนใหญ่สร้างเป็นผู้นำเสนอ” . ฉันเห็นตรงกันข้ามมากที่สุดโดยผู้นำเสนอเปิดทั้งรุ่นและมุมมอง มุมมองอาจเปิดตัวผู้นำเสนอด้วยเช่นกัน แต่ประเด็นนี้ไม่ได้โดดเด่นที่สุด สิ่งที่สำคัญที่สุดจะเกิดขึ้นในภายหลังในช่วงชีวิต

— Hibou57

2

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

— Ash

77

MVC (รุ่นมุมมองคอนโทรลเลอร์)

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

MVP (Model View Presenter)

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

สำหรับการอ้างอิงเพิ่มเติม

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

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

— viper

2

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

— Ash

2

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

— MegaManX

1

ฉันเห็นด้วยกับ Ash และ MegaManX ในแผนภาพ MVC ลูกศรควรมาจากมุมมองที่ชี้ไปที่โมเดล (หรือ ViewModel หรือ DTO) ไม่ใช่จากโมเดลไปยังมุมมอง เพราะรุ่นไม่ทราบเกี่ยวกับมุมมอง แต่มุมมองอาจรู้เกี่ยวกับรุ่น

— Jboy Flaga

57

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

ผู้ใช้: คลิกคลิก ...

View : นั่นใคร [ MVP | MVC ]

ผู้ใช้: ฉันเพิ่งคลิกที่ปุ่มค้นหา ...

ดู : โอเครอสักครู่…. [ MVP | MVC ]

( ดูการเรียกPresenter | Controller …) [ MVP | MVC ]

ดู : Hey Presenter | ผู้ควบคุมผู้ใช้เพิ่งคลิกที่ปุ่มค้นหาฉันต้องทำอย่างไร [ MVP | MVC ]

ผู้นำเสนอ | ผู้ควบคุม : เฮ้ดูมีคำค้นหาใดในหน้านั้นบ้าง [ MVP | MVC ]

ดู : ใช่…นี่คือ…“ เปียโน” [ MVP | MVC ]

ผู้นำเสนอ : ขอบคุณที่ดู …ในขณะที่ฉันกำลังค้นหาข้อความค้นหาในโมเดลโปรดแสดงแถบความคืบหน้าของเขา / เธอ [ MVP | MVC ]

( ผู้นำเสนอ | คอนโทรลเลอร์กำลังเรียกใช้โมเดล ... ) [ MVP | MVC ]

ผู้นำเสนอ | ตัวควบคุม : เฮ้โมเดลคุณมีอะไรที่ตรงกับคำค้นหานี้หรือไม่:“ piano” [ MVP | MVC ]

รุ่น : Hey Presenter | คอนโทรลเลอร์ให้ฉันตรวจสอบ ... [ MVP | MVC ]

( Modelกำลังสร้างการสืบค้นไปยังฐานข้อมูลภาพยนตร์ ... ) [ MVP | MVC ]

(หลังจากนั้นครู่หนึ่ง ... )

-------------- นี่คือจุดเริ่มต้นที่ MVP และ MVC แตกต่าง ---------------

แบบจำลอง : ฉันพบรายการสำหรับคุณPresenterที่นี่อยู่ใน JSON“ [{"ชื่อ": "อาจารย์สอนเปียโน", "ปี": 2001}, {"ชื่อ": "เปียโน", "ปี": 1993} ]” [ MVP ]

รุ่น : มีผลบางอย่างที่มีอยู่ควบคุม ฉันสร้างตัวแปรฟิลด์ในอินสแตนซ์ของฉันและเติมด้วยผลลัพธ์ ชื่อของมันคือ "searchResultsList" [ MVC ]

( Presenter | ControllerขอบคุณModelและกลับไปที่View ) [ MVP | MVC ]

ผู้นำเสนอ : ขอบคุณที่รอดูฉันพบรายการผลลัพธ์ที่ตรงกันสำหรับคุณและจัดเรียงในรูปแบบที่ทำได้: ["Piano Teacher 2001", "Piano 1993"] โปรดแสดงให้ผู้ใช้เห็นในรายการแนวตั้ง นอกจากนี้โปรดซ่อนแถบความคืบหน้าในขณะนี้ [ MVP ]

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

ดู : ขอบคุณPresenterมาก[ MVP ]

ดู : ขอบคุณ "ผู้ควบคุม" [ MVC ] (ตอนนี้มุมมองกำลังตั้งคำถามตัวเอง: ฉันจะนำเสนอผลลัพธ์ที่ฉันได้รับจากตัวแบบให้ผู้ใช้ได้อย่างไรปีการผลิตของภาพยนตร์เรื่องนี้มาเป็นอันดับแรกหรือครั้งสุดท้าย ... อยู่ในรายการแนวตั้งหรือแนวนอน? ... )

ในกรณีที่คุณสนใจฉันได้รับการเขียนบทความที่เกี่ยวข้องกับแอปรูปแบบสถาปัตยกรรม (MVC, MVP, MVVP สถาปัตยกรรมสะอาด, ... ) พร้อมด้วย Github repo ที่นี่ แม้ว่าตัวอย่างจะถูกเขียนขึ้นสำหรับ Android หลักการพื้นฐานที่สามารถนำไปใช้กับสื่อใด ๆ

— อาลีนีม
แหล่งที่มา

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

— Radu

@Radu, ไม่, ไม่ใช่ micromanage, นั่นคือสิ่งที่ผู้นำเสนอทำโดยทำมุมมองแบบพาสซีฟหรือเป็นใบ้

— Ali Nem

4

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

— Tommy Andersen

35

MVP = Model-View-Presenter
MVC = Model-View-Controller
1. ทั้งรูปแบบการนำเสนอ พวกเขาแยกการพึ่งพาระหว่างแบบจำลอง (คิดว่าวัตถุโดเมน) หน้าจอ / หน้าเว็บของคุณ (มุมมอง) และวิธีการที่ UI ของคุณควรจะทำงาน (ผู้นำเสนอ / ตัวควบคุม)
2. พวกเขาค่อนข้างคล้ายกันในแนวคิดผู้คนเริ่มต้น Presenter / Controller แตกต่างกันขึ้นอยู่กับรสนิยม
3. บทความที่ดีเกี่ยวกับความแตกต่างคือที่นี่ สิ่งที่น่าสังเกตมากที่สุดคือรูปแบบ MVC มีรูปแบบการอัพเดทมุมมอง

— Brett Veenstra
แหล่งที่มา

2

โมเดลอัปเดต VIew และนี่ยังเป็นระบบที่แยกออกจากกัน?

— Ash

34

Model-View-Controller

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

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

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

Model-View-Presenter

รูปแบบข้อมูลที่จะแสดงในมุมมอง (ส่วนติดต่อผู้ใช้)
มุมมองที่เป็นอินเตอร์เฟซที่แสดงข้อมูล (รุ่น) และเส้นทางคำสั่งของผู้ใช้ (เหตุการณ์) กับพรีเซนเตอร์ที่จะดำเนินการตามข้อมูลที่ มุมมองมักมีการอ้างอิงถึงผู้นำเสนอ
Presenterคือ“กลางคน” (รับบทโดยควบคุมใน MVC) และมีการอ้างอิงทั้งมุมมองและรูปแบบ โปรดทราบว่าคำว่า "Model"นั้นทำให้เข้าใจผิด มันค่อนข้างจะเป็นเหตุผลทางธุรกิจที่ดึงข้อมูลหรือปรุงแต่งรุ่น ตัวอย่างเช่น: หากคุณมีฐานข้อมูลที่จัดเก็บผู้ใช้ในตารางฐานข้อมูลและมุมมองของคุณต้องการแสดงรายการผู้ใช้ Presenter จะมีการอ้างอิงถึงตรรกะทางธุรกิจฐานข้อมูลของคุณ (เช่น DAO) จากที่ผู้นำเสนอจะสอบถามรายการ ของผู้ใช้

หากคุณต้องการดูตัวอย่างด้วยการใช้งานที่ง่ายโปรดตรวจสอบ โพสต์ GitHub นี้

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

อะไรคือความแตกต่างระหว่างรูปแบบMVCและMVP ?

รูปแบบ MVC

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

รูปแบบ MVP

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

— ราหุล
แหล่งที่มา

2

ไม่ได้มีการเชื่อมต่อโดยตรงระหว่างมุมมองและรุ่นใน mvc แผนภาพของคุณผิด

— Özgür

33

สิ่งที่ควรค่าแก่การจดจำก็คือ MVP ประเภทต่าง ๆ เช่นกัน ฟาวเลอร์ได้แบ่งรูปแบบออกเป็นสอง - มุมมองแบบพาสซีฟและตัวควบคุมกำกับดูแล

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

การใช้งานของคุณอาจมีลักษณะเช่นนี้:

public class CustomerView : ICustomerView
{
    public string Name
    { 
        get { return txtName.Text; }
        set { txtName.Text = value; }
    }
}

คลาสผู้นำเสนอของคุณจะพูดคุยกับโมเดลและ "แมป" กับมุมมอง วิธีการนี้เรียกว่า "มุมมองแบบพาสซีฟ" ข้อดีคือมุมมองนั้นง่ายต่อการทดสอบและง่ายต่อการย้ายไปมาระหว่างแพลตฟอร์ม UI (เว็บ, Windows / XAML, ฯลฯ ) ข้อเสียคือคุณไม่สามารถใช้ประโยชน์จากสิ่งต่าง ๆ เช่น databinding (ซึ่งมีประสิทธิภาพจริงๆในกรอบงานเช่นWPFและSilverlight )

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

"รส" ที่สามของ MVP (หรือบางคนอาจเรียกว่าเป็นรูปแบบที่แยกต่างหาก) คือรูปแบบการนำเสนอ (หรือบางครั้งเรียกว่า Model-View-ViewModel) เปรียบเทียบกับ MVP คุณ "รวม" M และ P เข้ากับคลาสเดียว คุณมีวัตถุลูกค้าของคุณซึ่งวิดเจ็ต UI ของคุณถูกผูกไว้กับข้อมูล แต่คุณยังมีฟิลด์ UI-spesific เพิ่มเติมเช่น "IsButtonEnabled" หรือ "IsReadOnly" เป็นต้น

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

ฉันยังได้ blogged เกี่ยวกับรูปแบบ Model-View-ViewModel ในบริบทของ Silverlight มากกว่าที่YouCard Re เข้าชม: การดำเนินการตามรูปแบบ

— Jonas Follesø
แหล่งที่มา

25

แต่ละรายการจะระบุปัญหาที่แตกต่างกันและสามารถรวมเข้าด้วยกันเพื่อให้มีสิ่งต่าง ๆ ดังต่อไปนี้

รูปแบบรวม

นอกจากนี้ยังมีการเปรียบเทียบที่สมบูรณ์ของ MVC, MVP และ MVVM ที่นี่

— Xiaoguo Ge
แหล่งที่มา

1

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

— Farid

18

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

มีการสนทนาที่นี่เกี่ยวกับความแตกต่างระหว่าง MVC กับ MVP

ความแตกต่างที่เกิดขึ้นก็คือในแอปพลิเคชั่น MVC แบบดั้งเดิมมีมุมมองและคอนโทรลเลอร์มีปฏิสัมพันธ์กับโมเดล แต่ไม่ใช่กับแต่ละอื่น ๆ

การออกแบบ MVP ทำให้ Presenter เข้าถึงโมเดลและโต้ตอบกับมุมมอง

ต้องบอกว่า ASP.NET MVC เป็นคำจำกัดความที่เป็นกรอบ MVP เพราะผู้ควบคุมเข้าถึงแบบจำลองเพื่อเติมมุมมองซึ่งมีความหมายว่าไม่มีตรรกะ (เพียงแค่แสดงตัวแปรที่จัดทำโดยคอนโทรลเลอร์)

หากต้องการทราบแนวคิดของ ASP.NET MVC ที่แตกต่างจาก MVP ลองดูงานนำเสนอ MIX นี้โดย Scott Hanselman

— แมตต์มิทเชล
แหล่งที่มา

7

MVC และ MVP เป็นรูปแบบไม่ใช่เฟรมเวิร์ก ถ้าคุณคิดอย่างสุจริตว่าหัวข้อนั้นเกี่ยวกับ. NET framework มันก็เหมือนกับการได้ยิน "อินเทอร์เน็ต" และคิดว่ามันเกี่ยวกับ IE

— tereško

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

— Matt Mitchell

13

ทั้งสองเป็นรูปแบบที่พยายามแยกงานนำเสนอและตรรกะทางธุรกิจแยกตรรกะทางธุรกิจออกจากส่วนของ UI

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

ทั้งคู่เปิดใช้งาน TDD และมีข้อเสียและอัพไซด์

การตัดสินใจเกี่ยวกับวิธีเลือกหนึ่งในนั้น IMHO ควรขึ้นอยู่กับเวลาที่ใช้ในการพัฒนาเว็บฟอร์ม ASP NET ถ้าใครคิดว่าตัวเองเก่งในเว็บฟอร์มฉันจะแนะนำ MVP หากใครรู้สึกไม่สะดวกใจกับสิ่งต่าง ๆ เช่นวงจรชีวิตของเพจเป็นต้น MVC อาจเป็นวิธีที่จะไปที่นี่

นี่เป็นอีกลิงค์โพสต์บล็อกที่ให้รายละเอียดเพิ่มเติมเล็กน้อยในหัวข้อนี้

http://blog.vuscode.com/malovicn/archive/2007/12/18/model-view-presenter-mvp-vs-model-view-controller-mvc.aspx

— Nikola Malovic
แหล่งที่มา

9

ฉันได้ใช้ทั้ง MVP และ MVC และแม้ว่าเราในฐานะนักพัฒนามักจะมุ่งเน้นไปที่ความแตกต่างทางเทคนิคของทั้งสองรูปแบบจุดสำหรับ MVP ใน IMHO นั้นเกี่ยวข้องกับความง่ายในการนำไปใช้มากกว่าสิ่งอื่น

ถ้าฉันทำงานในทีมที่มีพื้นหลังที่ดีในรูปแบบการพัฒนาเว็บฟอร์มมันง่ายกว่าการแนะนำ MVP มากกว่า MVC ฉันจะบอกว่า MVP ในสถานการณ์นี้เป็นชัยชนะที่รวดเร็ว

ประสบการณ์ของฉันบอกฉันว่าการย้ายทีมจากเว็บฟอร์มไปยัง MVP และจาก MVP เป็น MVC นั้นค่อนข้างง่าย การย้ายจากเว็บฟอร์มไปยัง MVC นั้นยากกว่า

ฉันปล่อยให้ลิงค์ไปยังบทความหลายเรื่องที่เพื่อนของฉันได้เผยแพร่เกี่ยวกับ MVP และ MVC

http://www.qsoft.be/post/Building-the-MVP-StoreFront-Gutthrie-style.aspx

— เปโดรซานโตส
แหล่งที่มา

8

ใน MVP มุมมองจะดึงข้อมูลจากผู้นำเสนอซึ่งดึงและจัดเตรียม / ทำให้ข้อมูลเป็นปกติจากโมเดลในขณะที่อยู่ใน MVC คอนโทรลเลอร์จะดึงข้อมูลจากโมเดลและชุดโดยกดในมุมมอง

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

MVP มักใช้กรอบการเชื่อมโยงบางประเภทเช่นกรอบการรวม Microsoft WPF หรือกรอบการเชื่อมโยงต่างๆสำหรับ HTML5 และ Java

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

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

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

เฟรมเวิร์กที่มีการเชื่อมโยงนี้ถ้าคุณตัดมันลงจริงๆแล้วมันเป็นคอนโทรลเลอร์

ดังนั้นคุณสามารถดู MVP เป็นวิวัฒนาการของ MVC

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

สรุป - MVP และ MVC เป็นทั้งรูปแบบ UI ที่แยกได้ แต่ MVP มักจะใช้กรอบการเชื่อมซึ่งเป็น MVC ภายใต้ THUS MVP อยู่ในระดับสถาปัตยกรรมที่สูงกว่า MVC และรูปแบบเสื้อคลุมด้านบนของ MVC

— James Roeiter
แหล่งที่มา

6

มุมมองสั้น ๆ ที่อ่อนน้อมถ่อมตนของฉัน: MVP สำหรับเครื่องชั่งขนาดใหญ่และ MVC สำหรับเครื่องชั่งขนาดเล็ก ด้วย MVC บางครั้งฉันรู้สึกว่า V และ C อาจถูกมองเห็นทั้งสองด้านของส่วนประกอบที่แยกไม่ออกได้เพียงด้านเดียวโดยตรงกับ M และสิ่งหนึ่งตกอยู่กับสิ่งนี้อย่างหลีกเลี่ยงไม่ได้เมื่อลดระดับ down ถึงระดับที่สั้นลงเช่นตัวควบคุม UI และวิดเจ็ตฐาน ในระดับของความละเอียดระดับนี้ MVP มีเหตุผลเล็กน้อย เมื่อสิ่งหนึ่งตรงกันข้ามกับเครื่องชั่งที่มีขนาดใหญ่ขึ้นอินเตอร์เฟซที่เหมาะสมจะมีความสำคัญมากกว่าเช่นเดียวกันกับการกำหนดความรับผิดชอบที่ชัดเจนและนี่คือ MVP

ในทางกลับกันกฎง่ายๆขนาดนี้อาจมีน้ำหนักน้อยมากเมื่อคุณลักษณะของแพลตฟอร์มสนับสนุนความสัมพันธ์ระหว่างส่วนประกอบบางอย่างเช่นกับเว็บซึ่งดูเหมือนว่าจะง่ายต่อการใช้ MVC มากกว่า MVP

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

4

ฉันคิดว่าภาพนี้โดย Erwin Vandervalk (และบทความประกอบ) เป็นคำอธิบายที่ดีที่สุดของ MVC, MVP และ MVVM ความคล้ายคลึงและความแตกต่างของพวกเขา บทความไม่ปรากฏขึ้นในผลการค้นหาสำหรับการค้นหาที่ "MVC, MVP และ MVVM" เพราะชื่อเรื่องของบทความไม่ได้มีคำว่า "MVC" และ "MVP"; แต่มันเป็นคำอธิบายที่ดีที่สุดฉันคิดว่า

ภาพอธิบาย MVC, MVP และ MVVM - โดย Erwin Vandervalk

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

— Jboy Flaga
แหล่งที่มา

3

MVC มีหลายรุ่นคำตอบนี้เกี่ยวกับ MVC ดั้งเดิมใน Smalltalk โดยย่อก็คือ

การพูดคุยนี้droidcon NYC 2017 - การออกแบบแอปที่สะอาดพร้อมองค์ประกอบสถาปัตยกรรมให้ความกระจ่าง

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

6

ใน MVC โมเดลจะไม่ถูกเรียกจากมุมมองโดยตรง

— rodi

5

นี่คือคำตอบที่ไม่ถูกต้อง อย่าหลงผิด ตามที่ @rodi เขียนไม่มีการโต้ตอบระหว่าง View และ Model

— Shawn Mehan

รูปภาพ MVC ไม่ถูกต้องหรือทำให้เข้าใจผิดได้ดีที่สุดโปรดอย่าใส่ใจคำตอบนี้

— Jay

2

@ Jay1b MVC อะไรที่คุณคิดว่า "ถูกต้อง"? คำตอบนี้เกี่ยวกับ MVC ดั้งเดิม มี MVC อื่น ๆ อีกมากมาย (เช่นใน iOS) ที่เปลี่ยนไปปรับให้เข้ากับแพลตฟอร์มพูดเช่นUIKit

— onmyway133

ลูกศรหมายถึงอะไร

— ปัญหา

3

นอกจากนี้วิดีโอที่ดีจากลุงบ๊อบซึ่งเขาอธิบายสั้น ๆ อธิบายMVCและMVPในตอนท้าย

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

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

ฉันหวังว่านี่จะช่วยได้ดีกว่า

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

2

จุดสำคัญจาก Uncle Bob: เมื่อคิดค้นโดย Trygve Reenskaug MVC มีความหมายสำหรับแต่ละวิดเจ็ตไม่ใช่แบบฟอร์มทั้งหมด

— Basil Bourque

2

คุณลืมเกี่ยวกับAction-Domain-Responder ( ADR )

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

บางคนลืมอยู่เสมอว่า MVC ถูกสร้างขึ้นในช่วงปลายปี 70 "และเว็บนั้นถูกสร้างขึ้นในช่วงปลายยุค 80" / ต้น 90 "เท่านั้น MVC ไม่ได้ถูกสร้างขึ้นสำหรับเว็บในตอนแรก , Model และ View จะอยู่ด้วยกัน

เนื่องจากเราใช้เว็บเฟรมเวิร์ก ( เช่น: Laravel ) ที่ยังคงใช้หลักการตั้งชื่อเดียวกัน ( model-view-controller ) เรามักจะคิดว่ามันต้องเป็น MVC แต่จริงๆแล้วมันเป็นอย่างอื่น

ให้ดูที่Action-Domain-Responderแทน ใน ADR ที่ควบคุมได้รับการดำเนินการซึ่งจะทำการดำเนินการในรุ่น / โดเมน จนถึงตอนนี้ก็เหมือนกัน ความแตกต่างคือจากนั้นจะรวบรวมการตอบสนอง / ข้อมูลของการดำเนินการนั้นและส่งต่อไปยังResponder ( เช่น:.view() ) เพื่อแสดงผล เมื่อมีการร้องขอการกระทำใหม่ในองค์ประกอบเดียวกันคอนโทรลเลอร์จะถูกเรียกอีกครั้งและรอบจะทำซ้ำตัวเอง ใน ADR ไม่มีการเชื่อมต่อระหว่างรุ่น / โดเมนกับมุมมอง ( การตอบกลับของผู้ตอบโต้ )

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

MVC ADR รุ่น View-Controller การกระทำโดเมนตอบกลับ

— Hugo Rafael Azevedo
แหล่งที่มา

2

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

— ไคลฟ์ Jefferies
แหล่งที่มา

ฉันลงคะแนนแล้วเพราะ afaik แบบจำลองไม่ทราบอะไรเกี่ยวกับมุมมองใน MVC และไม่สามารถอัปเดตโดยตรงในขณะที่คุณเขียน

— problemofficer

1

ดู MVC บน Wikipedia นั่นคือสิ่งที่มันใช้งานได้จริง

— ไคลฟ์ Jefferies

1

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

— underscore_d

1

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

— elysium กลืนกิน

ขอบคุณ .. มันช่วยฉันได้มาก

— Dvyn Resh

1

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

— Chinmai Kulkarni
แหล่งที่มา

-1

MVP

MVP ย่อมาจาก Model - View- Presenter นี่เป็นภาพเมื่อต้นปี 2550 ที่ Microsoft เปิดตัวแอพพลิเคชั่น Windows Smart Client

ผู้นำเสนอทำหน้าที่เป็นผู้ดูแลใน MVP ซึ่งเชื่อมโยงดูเหตุการณ์และตรรกะทางธุรกิจจากแบบจำลอง

การเชื่อมเหตุการณ์ดูจะถูกนำมาใช้ในผู้นำเสนอจากอินเทอร์เฟซมุมมอง

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

ข้อดี: มุมมองมี UI เพียงอย่างเดียวไม่ได้มีการทดสอบระดับสูง

ข้อด้อย: บิตที่ซับซ้อนและทำงานได้มากขึ้นเมื่อใช้การเชื่อมเหตุการณ์

MVC

MVC ย่อมาจาก Model-View-Controller คอนโทรลเลอร์มีหน้าที่สร้างโมเดลและแสดงมุมมองด้วยโมเดลที่มีผลผูกพัน

ตัวควบคุมเป็นตัวเริ่มต้นและจะตัดสินใจว่าจะให้มุมมองใด

จุดเด่น: เน้นหลักการความรับผิดชอบเดี่ยวทดสอบระดับสูง

จุดด้อย: บางครั้งภาระงานมากเกินไปสำหรับตัวควบคุมหากพยายามแสดงหลายมุมมองในตัวควบคุมเดียวกัน

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