เหตุใดฉันจึงควรใช้รูปแบบ MVC

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

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

หึ Martin Fowler เห็นด้วยกับความสับสนของคุณเกี่ยวกับ MVC:

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

อย่างไรก็ตามเขายังคงให้คำอธิบายที่ตรงประเด็นมากกว่าสิ่งที่กระตุ้น MVC:

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

คุณสามารถอ่านบทความทั้งหมดของพรานล่าสัตว์ที่นี่

ฉันรู้สึกว่าสิ่งนี้ขึ้นอยู่กับปัญหาที่คุณต้องแก้ไข ฉันเห็นการแยกดังนี้:

รุ่น - เราจะแสดงข้อมูลอย่างไร ตัวอย่างเช่นฉันจะไปจากวัตถุของฉันไปยังที่เก็บข้อมูลถาวรเช่น DB -> ฉันจะบันทึกวัตถุ 'ผู้ใช้' ของฉันไปยังฐานข้อมูลได้อย่างไร

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

ดู - ฉันจะแสดงผลลัพธ์ได้อย่างไร

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

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

คุณไม่ควร

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

มาจาก CI และ Yii ฉันคิดว่าการมีตัวควบคุมเฉพาะเป็นไอเดียที่เจ๋งจริงๆ อย่างไรก็ตามเมื่อพัฒนาแอพพลิเคชั่นที่มีอินเตอร์เฟส RESTful ที่เหมาะสมดังนั้นความต้องการตัวควบคุมในการจัดการกับลอจิกแบบไม่เฉพาะรุ่นจึงดูเหมือนว่าจะลดน้อยลง ดังนั้นเมื่อย้ายไปที่ Django แล้ว Pyramid (ซึ่งไม่เป็นไปตามสถาปัตยกรรม MVC ทั้งหมด) ฉันพบว่าคอนโทรลเลอร์ไม่ได้เป็นองค์ประกอบที่จำเป็นสำหรับแอปพลิเคชันที่ฉันกำลังสร้าง โปรดทราบว่าเฟรมเวิร์กทั้งสองมีคุณสมบัติ "controller'ish" เช่น URL Dispatching ใน Pyramid แต่เป็นสิ่งที่กำหนดค่าไม่ใช่สิ่งรันไทม์ (เช่น CController ใน Yii)

ในตอนท้ายของวันสิ่งที่สำคัญจริงๆคือการแยกมุมมองจากตรรกะ ไม่เพียง แต่ทำความสะอาดสิ่งนี้ในแง่ของการใช้งาน แต่ยังช่วยให้วิศวกร FE / BE สามารถทำงานแบบขนาน (เมื่อทำงานในสภาพแวดล้อมแบบทีม)

(หมายเหตุด้านข้าง: ฉันไม่ได้พัฒนาเว็บแอพอย่างมืออาชีพดังนั้นอาจมีบางอย่างที่ฉันขาดหายไป)

ใช่คำศัพท์เกี่ยวกับเรื่องนี้เป็นระเบียบ มันยากที่จะพูดถึงเพราะคุณไม่เคยเข้าใจความหมายของคำศัพท์

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

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

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

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

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

ฉันคิดว่า MVC ใช้คำศัพท์เพียงคำเดียวโดยนักทฤษฎีที่เป็นผู้จัดการ อย่างไรก็ตามเมื่อกล่าวว่าการทำซ้ำของเว็บในปัจจุบันด้วย HTML5 ที่แพร่หลายการออกแบบที่ตอบสนองและพยายามสร้างโปรแกรมฐานข้อมูลบรรทัดเดียวที่จะทำงานบนเว็บและบน iPhone ให้ยืมกับแนวคิดทั่วไปของ MVC เทคโนโลยีหน้าเว็บกำลังเคลื่อนที่ด้วยความเร็วของแสงอย่างแท้จริงในขณะนี้ด้วย Jquery การวนซ้ำใหม่ของการควบคุม CSS ในขณะที่ฝั่งเซิร์ฟเวอร์ของสิ่งต่าง ๆ กำลังเคลื่อนไหวอย่างรวดเร็ว

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

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