ฉันต้องการอธิบาย MVC ให้ผู้ที่ไม่ใช่โปรแกรมเมอร์ คือผู้จัดการของแผนกอื่น ๆ ในบริบทของรายงานความคืบหน้า หนึ่งในสิ่งที่ฉันทำคือ refactor codebase ของเราไปสู่การแยก MVC

พวกเขาอาจถามแยก MVC คืออะไร? ทำไมพวกเขาอาจจำเป็นต้องถาม?

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

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

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

คุณไม่ได้อธิบาย MVC

สิ่งที่คุณทำคืออธิบายว่านี่เป็นการปรับโครงสร้างของ codebase

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

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

กล่าวอีกนัยหนึ่ง - พูดภาษาของพวกเขากับพวกเขา

ในขณะที่ฉันรับรองส่วนสำคัญของคำตอบของ Odedที่คุณควรอธิบายโครงการด้านเทคนิคให้กับผู้จัดการธุรกิจใน "ภาษาของพวกเขา" ฉันมีความมั่นใจเกี่ยวกับ "พวกเขาไม่จำเป็นต้องรู้รายละเอียดทางเทคนิค

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

ดังนั้นมีร่างของ MVC ในกระเป๋าสะโพกของคุณพร้อมที่จะไป สิ่งที่ต้องการ:

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

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

เพื่อปรับปรุงความยืดหยุ่นในการเปลี่ยนแปลงซอฟต์แวร์

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

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

มันเป็นกลยุทธ์ทั่วไปดังนั้นการจ้างนักพัฒนาใหม่ไม่ควรมีปัญหา ในความเป็นจริงคุณอาจดึงดูดนักพัฒนาที่ดีกว่าซึ่งเป็นผู้สนับสนุนที่แข็งแกร่ง

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

• รุ่น - สายไฟ / ไฟฟ้า
• มุมมอง - โคมไฟ
• คอนโทรลเลอร์ - สวิตช์ไฟ

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

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

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

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

รูบริกที่ดีที่สุดเท่าที่เคยมีมา: "เราต้องการรุ่น SMART, คอนโทรลเลอร์ THIN และมุมมอง DUMB"

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

ตัวแปร MVC ทั้งหมดใช้การแบ่งส่วนประกอบเดียวกัน แต่โดยทั่วไปแล้วจะแตกต่างกันในการที่องค์ประกอบเหล่านั้นโต้ตอบกัน

สำหรับบรรดาของคุณที่ไม่ทราบ, MVC ได้อธิบายไว้เดิมในแง่ของรูปแบบการออกแบบสำหรับการใช้งานกับสมอลล์ทอล์คโดย Trygve Reenskaug ในปี 1979 บทความของเขาถูกตีพิมพ์ภายใต้หัวข้อ "การเขียนโปรแกรมประยุกต์ใน Smalltalk-80: วิธีการใช้ Model-View-Controller" และปูพื้นฐานสำหรับการใช้งาน MVC ในอนาคต

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

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

กันเลยลองตอบคำถาม:

ฉันพบว่ามีประโยชน์ในการใช้การเปรียบเทียบที่นักธุรกิจเข้าใจ สำหรับ MVC ฉันอธิบายว่าเป็นธุรกิจ

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

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

หวังว่าจะตอบ "อะไร" - "ทำไม" ก็ง่ายด้วยการเปรียบเทียบนี้:

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

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

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

ประโยชน์ของ MVC เป็นหลักในการแยกความกังวล:

ช่วยให้ผู้คนมีสมาธิกับสิ่งที่พวกเขาทำได้ดีที่สุด

Database admins develop the model
Programmers write the controllers
and Graphic designers can design the views.

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

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

ฉันจะบอกพวกเขาว่า MVC แยกข้อกังวลของฉัน

ข้อกังวลแรกของฉันคือตรรกะของรหัส - สิ่งที่ฉันทำอยู่เบื้องหลังเพื่อทำให้เว็บไซต์ดำเนินการตามที่พวกเขาต้องการ

ข้อกังวลประการที่สองของฉันคือตรรกะทางธุรกิจ - สิ่งที่พวกเขา (ผู้ใช้) ต้องการให้แอปพลิเคชันทำ

ข้อกังวลประการที่สามของฉันคือลักษณะของเว็บไซต์ - หน้าเว็บที่พวกเขาเข้าชมทำในสิ่งที่พวกเขาต้องการ

(ฉันไม่ได้บอกพวกเขาในส่วนต่อไปนี้) ดังนั้นตามคำอธิบายของฉันก็คือ Model, Controller และ View

อธิบายข้อดี

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

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

นางแบบ

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

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

นอกจากนี้คุณยังสามารถขยายแอพพลิเคชั่นได้อย่างง่ายดายโดยการเพิ่มรุ่นอื่น ๆ มันเป็นโมดูลและสะอาดมาก

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

มุมมอง

การแยกมุมมองออกทำให้คุณสามารถอัปเดตส่วนหน้าได้อย่างง่ายดายโดยไม่ทำให้ส่วนหลังขาด

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

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

ผู้ควบคุม

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

ข้อดีอื่น ๆ

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

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

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