อะไรคือความพินาศของ MVC [ปิด]

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

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

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

คุณควรจำไว้เสมอ - MVC เป็นรูปแบบที่เกี่ยวข้องกับ UI หากคุณกำลังสร้างแอพพลิเคชั่นที่ซับซ้อนคุณควรนำทุกอย่างที่ไม่เกี่ยวข้องกับ UI ออกจาก MVC triplets ไปยังคลาสระบบย่อยหรือเลเยอร์อื่น ๆ

มันเป็นความผิดพลาดครั้งใหญ่ที่สุดของฉัน ฉันใช้เวลานานเข้าใจกฎง่ายๆว่า

• อย่ากระจายรูปแบบ MVC ระหว่างแอปพลิเคชันทั้งหมด
• จำกัด เฉพาะสิ่งที่เกี่ยวข้องกับ UI เท่านั้น

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

รูปแบบทั้งหมดที่คุณเรียกว่าทางเลือก MVC (เช่น Model-View-Presenter, Model-View-ViewModel) เป็นเพียงวิธีการนำแนวคิด MVC ทั่วไปมาใช้

ในความคิดของฉันมี MVC สองประเภท - บริสุทธิ์และไม่บริสุทธิ์ (สำหรับการขาดคำดีกว่า :)

MVC บริสุทธิ์คือสิ่งที่นำมาพูดคุยเล็กน้อย:

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

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

• รุ่น : นามธรรมสำหรับข้อมูลที่เก็บไว้
• การควบคุม : โดยทั่วไปสิ่งที่เรียกว่าเลเยอร์ตรรกะทางธุรกิจรวมถึงส่วนหนึ่งของแอปพลิเคชันที่รับผิดชอบในการกำหนดเส้นทางคำขอ HTTP ไปยังตรรกะทางธุรกิจที่เกี่ยวข้อง (ตัวควบคุม aka)
• มุมมอง : ส่วนใหญ่ดูเทมเพลตที่จัดรูปแบบข้อมูลจากโมเดลและส่งคืนไปยังไคลเอ็นต์ โมเดลไม่เคยส่งการอัปเดตไปยังมุมมองและมุมมอง 'สมัครสมาชิก' สำหรับการอัปเดตจากโมเดล มันจะเป็นฝันร้ายที่มีเพศสัมพันธ์ ดังนั้นมันจึงเหมือนกับ PAC มากกว่า MVC จริง

ต่อไปนี้เป็นวิธีที่โครงสร้างเว็บแอปพลิเคชันมักจะ:

1. Front-end : MVC บนไคลเอนต์ที่ใช้เฟรมเวิร์กเป็น Backbone.js เป็นต้นนี่คือรูปแบบ MVC ที่ 'จริง' ในสาระสำคัญ
2. แบ็คเอนด์ : อีกครั้งคุณมี (ไม่บริสุทธิ์) MVC / PAC สำหรับการจัดระเบียบรหัสและการแยกข้อกังวล
3. เว็บแอปทั่วโลก (สำหรับเว็บแอปพลิเคชันโดยรวม): หากคุณมีแบ็กเอนด์ RESTful ที่ส่งคืนข้อมูล JSON เท่านั้นแบ็กเอนด์ทั้งหมดของคุณจะถูกรับรู้เป็นแบบจำลองสำหรับแอปพลิเคชันไคลเอนต์ Front-end

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

คุณควรใช้มันทุกที่หรือไม่? อาจจะไม่. เว็บแอปพลิเคชั่นที่ซับซ้อนมากอาจแบ่งเป็นหลายเลเยอร์! คุณอาจไม่สามารถออกไปได้ด้วยเลเยอร์ View / Business Logic / Data กรอบ / องค์กรที่ครอบคลุมอาจยังคงเป็น MVC-ish แต่เฉพาะในระดับมหภาค

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

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

หากคุณทำงานในที่เดียวได้สักพักคุณสามารถออกเดทกับโค้ดได้เกือบทั้งชิ้นโดยดูว่าเทคโนโลยี / รูปแบบการออกแบบ / การปฏิบัตินั้นเป็นอย่างไรในสมัยนั้นเช่น singletons / dependency injection / TDD เป็นต้น

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

ปัญหาไม่ค่อยเกิดขึ้นกับแนวคิด - มากกว่าด้วยการนำไปใช้ ไม่ว่ากระบวนทัศน์ที่ดีเพียงใดใช้เวลาในการดูว่าเหมาะกับปัญหาในมือหรือไม่

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

ทางเลือกสำหรับปัญหาแรกคือการแยกรหัสดังกล่าวออกเป็นโครงการย่อยอิสระ ทางเลือกสำหรับที่สองคือรหัสที่ไม่แยกกันไม่ว่าจะเป็นที่คลาสหรือรุ่นของไฟล์

ความเข้าใจของฉันเกี่ยวกับการใช้ MVC / MV * เป็นไปตามหลักการของการแยกข้อกังวล (SoC) - การแยกโปรแกรม / รหัสออกเป็นส่วน / ชิ้นที่แตกต่างกันเพื่อให้แต่ละส่วนสามารถแก้ไขข้อกังวลแยกต่างหากได้ (Ref: http://en.wikipedia.org / wiki / Separation_of_concerns )

มีประโยชน์มากมายเมื่อแยกข้อกังวล: หนึ่งจะไม่ส่งผลกระทบต่ออีกและนักพัฒนาสามารถทำงานในหน่วยโดยไม่ส่งผลกระทบต่อส่วนที่เหลือ ฯลฯ & ฯลฯ ... MVC ไม่ใช่รูปแบบเดียวที่ตาม SoC โดยทั่วไป OOP เองคือ แนวคิดที่ยอดเยี่ยมในการแบ่งสิ่งต่าง ๆ ออกเป็นหน่วยต่างๆ

MVC / MV * มีประโยชน์มากเมื่อคุณจัดการกับการพัฒนา UI ที่เกี่ยวข้องในขณะที่ภายใต้อาจมีรูปแบบมากขึ้น - โรงงาน, ซิงเกิลตัน, ซุ้มและอื่น ๆ ส่วนใหญ่ของโครงการขนาดใหญ่ประกอบด้วยหลายชั้นที่จัดการด้านต่าง ๆ แต่ UI อาจไม่จำเป็นสำหรับ บางกรณี. คุณอาจเห็น MVC เป็นจำนวนมาก - นั่นเป็นเพราะโครงการจำนวนมากมีองค์ประกอบ UI

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

ดังนั้นเพื่อประเมิน MVC (หรือมากกว่าทั่วไป - รูปแบบการออกแบบ) ให้บริบทและคิดถึงความซับซ้อนความสามารถในการปรับขนาดการทดสอบการบำรุงรักษาข้อ จำกัด ด้านเวลา ฯลฯ และอื่น ๆ