การออกแบบรุ่นที่เหมาะสม - ดู -_____

ฉันได้อ่านเกี่ยวกับ Model View Controller, Model View Presenter, Model View ViewModel เป็นต้นโดยทั่วไปแนวคิดพื้นฐานดูเหมือนจะเข้าใจง่าย: เก็บภาพที่สวยงามและความกล้าหาญทางวิทยาศาสตร์แยกจากกันและงมงายเป็น เป็นไปได้ ไม่ได้รับเนยถั่วลิสงในการออกแบบช็อคโกแลต; ฉันชอบมัน

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

ฉันเที่ยว

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

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

หมายเหตุ: ฉันจะใช้ "the Bridge" สำหรับส่วนที่สามอันลึกลับของ Model-View-? เพื่อหลีกเลี่ยงคำแนะนำจิตใต้สำนึกของสิ่งที่ "ควร" เป็น

แบบ

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

ดู

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

สะพาน

• เป็นผู้ประสานงานและนักแปลระหว่างรุ่นและมุมมอง
• ทำการเปลี่ยนแปลงการจัดรูปแบบที่เหมาะสมกับข้อมูลที่ส่งผ่านระหว่างรูปแบบและมุมมอง
• เก็บข้อมูลเกี่ยวกับ "ผู้ที่ต้องการรู้ว่าอะไร"
• มีความรู้ทั้งใน Model และ the View

หมายเหตุเพิ่มเติม

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

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

และเช่นเคยขอบคุณสำหรับเวลาของคุณ

วลีของคุณ

"เป็นผู้ประสานงานและผู้แปลระหว่างรุ่นและมุมมอง"

ระบุว่าบริดจ์ของคุณคือผู้นำเสนอในสถาปัตยกรรม MVP

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

โมเดลความรับผิดชอบของคุณ

"แจ้งสะพานเมื่อมีการเปลี่ยนแปลงข้อมูล (สำหรับข้อมูลที่สะพานแสดงความสนใจ)"

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

"อนุญาตให้ผู้สมัครสมาชิกภายนอก (เกี่ยวกับสิ่งที่ไม่รู้) เพื่อตรวจสอบสถานะหรือผลการคำนวณ"

หากรุ่นของคุณไม่มีการพึ่งพาตัวควบคุมหรือมุมมองของคุณการทดสอบและพกพาได้ง่ายกว่ามาก

ฉันสงสัยว่าสิ่งหนึ่งที่ทำให้คุณสับสนคือมีสองรูปแบบที่แตกต่างกันโดยสิ้นเชิงซึ่งทั้งสองเรียกว่า model-view-controller

มีต้นฉบับตามที่นำมาใช้ใน smalltalk และเป็นประโยชน์สำหรับระบบ gui ในพื้นที่และมีสิ่งที่ฉันมักจะคิดว่าเป็น web-mvc ซึ่งสลับไปมารอบ ๆ บางส่วนของมุมมองและตัวควบคุมเพื่อให้ตัวควบคุมสามารถนั่งบนเซิร์ฟเวอร์ด้วย มุมมองที่อยู่บนไคลเอนต์ (อาจเป็น html ที่แสดงผลหรืออาจผ่าน ajax)

คำอธิบายของคุณดูเหมือนจะเป็นคำจำกัดความของ web-mvc

มีการถกเถียงกันอย่างมากในชุมชนการเขียนโปรแกรมเกี่ยวกับระบบการตั้งชื่อที่แน่นอนนี้ ดูเหมือนว่าไม่มีใครเห็นด้วยกับอะไรมาก

สำหรับฉันแล้วสะพานเชื่อมต่อกับมุมมองส่วนใหญ่กำหนดชื่ออย่างไร

• หากสามารถมีการรวบรวมจำนวนการดูต่อบริดจ์ดังนั้นบริดจ์จะเป็นคอนโทรลเลอร์
• หากมีหนึ่งมุมมองต่อหนึ่งบริดจ์เสมอบริดจ์จะเป็นผู้นำเสนอ
• หากสามารถมีการรวบรวมบริดจ์ต่อการดูดังนั้นบริดจ์เป็นโมเดลการดู

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

ในฐานะที่เป็นข้อความด้านข้างฉันชอบจับคู่ความรับผิดชอบเช่นนี้:

แบบ

ความรับผิดชอบหลัก: ข้อมูลที่มีอยู่
บทบาทรอง: ตรวจสอบการอัพเดทแจ้งผู้สังเกตการณ์การอัพเดท

ดู

ความรับผิดชอบหลัก: ข้อมูลปัจจุบัน
บทบาทรอง: ยอมรับอินพุตนำเสนอ UX

สะพาน

ความรับผิดชอบหลัก: อัปเดตข้อมูล
บทบาทรอง: ล้างอินพุตซิงค์ข้อมูลและมุมมอง

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

ฉันขอแนะนำให้ขยายความคิดของคุณโดยใช้รูปแบบต่อไปนี้ (นำมาจากการพูดคุยของศัตรูของรัฐ Amy Palamountain ):

รุ่น

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

เข้าชม

• เทมเพลตการแสดงผล
• จัดการกับโมเดลเหตุการณ์
• จัดการกับเหตุการณ์ DOM
• เป็นสื่อกลางในการโต้ตอบระหว่าง Model และ DOM

ตัวควบคุม

• จัดการมากที่สุดสองสามโมเดลและมุมมอง
• ติดตามการดูภายในคอนเทนเนอร์

โมดูล

• การจัดกลุ่มแบบลอจิคัลของคอนโทรลเลอร์และมุมมองและโมเดล
• ทดสอบ
• ขนาดเล็กและบำรุงรักษาได้ (ความรับผิดชอบเดียว)
• พิกัด (ผ่านตัวควบคุม) สถานะและเหตุการณ์ของ Views & Model ที่มี
• ฟรีเพื่อนำเสนอมุมมองของตัวเอง
• ไม่สามารถเลือกตำแหน่งที่จะนำเสนอมุมมองได้

เครื่องมือจัดการเค้าโครง

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

ผู้จัดการ

• ฟังเหตุการณ์ (ผ่านสตรีม PubSub ระดับโลก)
• รับผิดชอบในการโหลดโมดูลใหม่ตามกิจกรรม
• ส่งโมดูลที่โหลดไปยัง Layout Manager
• จัดการอายุการใช้งานโมดูลทั้งหมด (การสร้างล้างแคช ฯลฯ )
• ตัวอย่างเหตุการณ์:
  • การเปลี่ยนเส้นทาง (รวมถึงเส้นทางโหลดเริ่มต้น)
  • ปฏิสัมพันธ์ของผู้ใช้
  • เหตุการณ์โมดูลเดือดดาลจากเหตุการณ์ Model เนื่องจากการเปลี่ยนแปลงสถานะฝั่งเซิร์ฟเวอร์ ฯลฯ

ใบสมัคร

• รับผิดชอบการตั้งค่าโดยรวมทำให้สิ่งต่าง ๆ เช่น:
  • ผู้จัดการ
  • Router
  • กระแส PubSub
  • ตัดไม้
  • ฯลฯ

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

ตามที่เอมี่ชี้ให้เห็น: ระวังอย่าสร้างเซิร์ฟเวอร์บนไคลเอนต์ และระวังไม่ให้ตกอยู่ในหลักคำสอนของ "ฉันกำลังทำกรอบ MV * ดังนั้นฉันต้อง ___!" ให้ใช้แนวคิดเหล่านี้ทั้งหมด (และคำตอบอื่น ๆ ที่นี่) และค้นหาสิ่งที่ดีที่สุดสำหรับแอปพลิเคชันและทีมของคุณ

ผมขอแนะนำให้ดูการพูดคุยเอมี่ Palamountain ของศัตรูของรัฐ (จากการที่ความคิดเหล่านี้มา) หรืออย่างน้อยเพื่อดูมากกว่าภาพนิ่งจากการพูดคุย