MVC คืออะไรจริงเหรอ?

ในฐานะโปรแกรมเมอร์ที่จริงจังคุณจะตอบคำถามMVC คืออะไรได้อย่างไร

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

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

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

ดังนั้นฉันจะอธิบาย MVCในวิธีที่ถูกต้องกระชับและไม่ขัดแย้งได้อย่างไร

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

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

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

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

โดยสรุปส่วนประกอบทั้งสามนี้ทำงานร่วมกันเพื่อสร้างองค์ประกอบพื้นฐานสามประการของ MVC

การเปรียบเทียบ

ฉันอธิบาย MVC ให้พ่อของฉันเช่นนี้:

MVC (Model, View, Controller) เป็นรูปแบบสำหรับการจัดระเบียบโค้ดในแอปพลิเคชันเพื่อปรับปรุงการบำรุงรักษา

ลองนึกภาพช่างภาพด้วยกล้องของเขาในสตูดิโอ ลูกค้าขอให้เขาถ่ายรูปกล่อง

กล่องเป็นรุ่นช่างภาพเป็นตัวควบคุมและกล้องเป็นมุมมอง

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

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

คำอธิบายโดยละเอียด

มันเป็นเพียงหลังจากอ่านคำถาม / คำตอบของนักเขียนต่อไปนี้ที่ฉันรู้สึกเหมือนฉันเข้าใจ MVC อ้างอิง: https://mail.python.org/pipermail/python-list/2006- มกราคม/394968.html

bwaha wrote:

ผู้เขียนอ้างถึง mvctree.py ใน wxPython เป็นตัวอย่างของการออกแบบ MVC อย่างไรก็ตามฉันยังเป็นสีเขียวเกินไปดังนั้นฉันจึงพบว่าตัวอย่างที่ซับซ้อนเกินไปและฉันไม่เข้าใจถึงการแยกที่ผู้เขียนแนะนำ

MVC คือทั้งหมดที่เกี่ยวกับการแยกความกังวล

ตัวแบบมีหน้าที่ในการจัดการข้อมูลของโปรแกรม (ทั้งข้อมูลส่วนตัวและข้อมูลลูกค้า) View / Controller รับผิดชอบในการจัดหาโลกภายนอกด้วยวิธีการโต้ตอบกับข้อมูลลูกค้าของโปรแกรม

รุ่นนี้มีอินเทอร์เฟซภายใน (API) เพื่อให้ส่วนอื่น ๆ ของโปรแกรมโต้ตอบกับมัน View / Controller จัดเตรียมอินเทอร์เฟซภายนอก (GUI / CLI / เว็บฟอร์ม / IPC ระดับสูง / ฯลฯ ) เพื่อเปิดใช้งานทุกอย่างที่อยู่นอกโปรแกรมเพื่อสื่อสารกับมัน

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

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

ตอนนี้นี่คือการทดสอบการออกแบบ MVC ที่แท้จริง: โปรแกรมควรจะทำงานได้อย่างสมบูรณ์แม้ว่าจะไม่มี View / Controller ติดอยู่ก็ตาม ตกลงโลกภายนอกจะมีปัญหาในการโต้ตอบกับมันในรูปแบบนั้น แต่ตราบใดที่ใคร ๆ รู้ถึงคาถา API แบบเหมาะสมโปรแกรมจะเก็บและจัดการข้อมูลตามปกติ

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

ทำไม? เพราะใน MVC ในขณะที่มุมมอง / คอนโทรลเลอร์ได้รับอนุญาตให้รู้เล็กน้อยเกี่ยวกับ Model (โดยเฉพาะ API ของ Model) แต่ Model นั้นไม่ได้รับอนุญาตให้รู้อะไรเกี่ยวกับ View / Controller

ทำไม? เนื่องจาก MVC เป็นเรื่องเกี่ยวกับการสร้างการแยกข้อกังวลอย่างชัดเจน

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

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

ในทางปฏิบัติแล้ววัตถุ View / Controller อาจผ่าน API ของ Model 1 บอกให้ Model ทำสิ่งต่าง ๆ (รันคำสั่ง) และ 2 บอก Model ให้สิ่งต่าง ๆ (ส่งคืนข้อมูล) ชั้น View / Controller ส่ง คำแนะนำไปยังเลเยอร์ Model และดึงข้อมูลจากเลเยอร์ Model

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

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

ตอนนี้ปริศนาสุดท้ายที่ผ่านมาอย่างที่ฉันบอกไว้ก่อนหน้านี้: คุณจะทำให้จอแสดงผลของ UI ตรงกับสถานะของรุ่นในระบบที่ใช้ MVC ได้อย่างไร

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

แต่อย่างไร รูปแบบ MVC ป้องกันไม่ให้ Model ส่งสำเนาของข้อมูลนั้นไปยังเลเยอร์ View Heck ไม่อนุญาตให้ตัวแบบส่งข้อความดูว่าสถานะมีการเปลี่ยนแปลง

เกือบแล้ว ตกลงเลเยอร์โมเดลไม่ได้รับอนุญาตให้พูดคุยโดยตรงกับเลเยอร์อื่นเนื่องจากจะต้องมีความรู้เกี่ยวกับเลเยอร์เหล่านั้นและกฎ MVC จะป้องกันไม่ให้ อย่างไรก็ตามหากต้นไม้ล้มลงในป่าและไม่มีใครได้ยินเสียงมันจะส่งเสียงหรือไม่?

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

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

...

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

ไชโย

มี

MVC ส่วนใหญ่เป็นคำศัพท์

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

MVC ไม่ได้หมายถึงการอธิบายเว็บแอปพลิเคชัน
หรือระบบปฏิบัติการที่ทันสมัยหรือภาษา
(บางคนทำข้อกำหนด 1979 ซ้ำซ้อนจริง ๆ )

มันถูกสร้างขึ้นมาเพื่อ และมันก็ไม่ได้ผล

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

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

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

เว็บไซต์ / เว็บแอปพลิเคชันในยุค 90 ไม่ได้ใช้เพื่อแยกความกังวล

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

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

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

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

วิธีที่ดีที่สุดในการกำหนดคือไปที่งานเขียนต้นฉบับของTrygve Reenskaugผู้คิดค้นมัน: http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

โดยเฉพาะอย่างยิ่งบทความนี้ถือว่าเป็นข้อความแบบกำหนดเงื่อนไข: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

MODELS

แบบจำลองแสดงถึงความรู้ แบบจำลองอาจเป็นวัตถุเดียว (ค่อนข้างไม่น่าสนใจ) หรืออาจเป็นโครงสร้างของวัตถุ ...

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

โหนดของแบบจำลองทั้งหมดควรอยู่ในระดับปัญหาเดียวกันมันสับสนและถือว่าเป็นรูปแบบที่ไม่ดีในการผสมปมปัญหา (เช่นการนัดหมายในปฏิทิน) กับรายละเอียดการใช้งาน (เช่นย่อหน้า)

VIEWS

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

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

คอนโทรลเลอร์

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

ตัวควบคุมไม่ควรเสริมมุมมองเช่นไม่ควรเชื่อมต่อมุมมองของโหนดโดยการวาดลูกศรระหว่างพวกเขา

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

บรรณาธิการ

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

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

MVC เป็นรูปแบบการออกแบบที่ใช้เพื่อแยกตรรกะทางธุรกิจออกจากการนำเสนอ

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

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

MVC เป็นการออกแบบซอฟต์แวร์ที่แยกส่วนประกอบต่อไปนี้ของระบบหรือระบบย่อย:

1. รุ่น - ข้อมูลเกี่ยวกับสถานะของแอปพลิเคชันหรือส่วนประกอบ อาจรวมถึงกิจวัตรสำหรับการแก้ไขหรือการเข้าถึง
2. มุมมอง - การตีความข้อมูล (รุ่น) สิ่งนี้ จำกัด เฉพาะการแสดงภาพ แต่อาจเป็นเสียงข้อมูลที่ได้รับ (เช่นสถิติที่ส่งไปยังวัตถุรูปแบบอื่น) เป็นต้นนอกจากนี้แบบจำลองเดียวอาจมีหลายมุมมอง
3. การควบคุม - จัดการอินพุตภายนอกเข้ากับระบบที่เรียกใช้การดัดแปลงบนโมเดล การควบคุม / มุมมองอาจเกี่ยวข้องอย่างใกล้ชิด (ในกรณีของ UI) อย่างไรก็ตามอินพุตภายนอกอื่น ๆ (เช่นคำสั่งเครือข่าย) อาจถูกประมวลผลซึ่งไม่เกี่ยวข้องกับมุมมองทั้งหมด

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

ฉันคิดว่าบทความนี้คุ้มค่าที่จะอ่าน สถาปัตยกรรม GUI โดย Martin Fowler

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

คุณสามารถถามว่าพวกเขาอ้างถึง MVC โดยทั่วไปการใช้งานเฉพาะของ MVC (เช่น asp.net MVC, สปริง MVC, smalltalk MVC, ฯลฯ .. ) สิ่งที่มันเป็นในทางเทคนิคสิ่งที่มันเป็น philisophically (ใช่มันมี ปรัชญาเช่นกัน) ฯลฯ

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

คำตอบที่ดีและเรียบง่ายคือ:

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

คุณสามารถพูดได้ว่า:

ด้วยการแยกมุมมองจากตัวควบคุมจากตัวแบบจำลองมันส่งเสริมการแยกส่วนประกอบตามความรับผิดชอบของพวกเขา ในทางทฤษฎีและโดยทั่วไปแล้วในทางปฏิบัติสิ่งนี้จะช่วยปรับปรุงการบำรุงรักษาโดยการป้องกันส่วนต่าง ๆ ของระบบจากการรวมกลุ่มและการสร้างระบบที่ซับซ้อนมากขึ้น

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

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

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

ตอนนี้มีการใช้งานไม่มากนักในการนำเสนอเลย์เอาต์ xml ที่ดีและมีความคมชัดของคุณ สมมติว่าเราต้องการจัดเก็บข้อมูลที่ผู้ใช้ป้อน กิจกรรมต้องจัดการกับกระบวนการนี้ไม่ให้นำข้อมูลจากผู้ใช้ไปส่งให้กับบุคคลอื่นเพื่อจัดการ (กระบวนการจัดเก็บลบออก) ใครจะผ่านไป ดีกับMODEL ฉันชอบคิดว่าแบบจำลองเป็นของแท้ คลาสjavaที่ไม่รู้อะไรเลยเกี่ยวกับบริบทของแอปพลิเคชันมันอาศัยอยู่ (ในทางปฏิบัติที่แทบจะไม่เป็นเช่นนั้น)

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

ฉันมักจะเริ่มต้นด้วยการบอกพวกเขาว่ารูปแบบไม่ได้เป็นอะไรใหม่และมีมานานหลายปี ... ณ จุดนี้พวกเขาทำให้ฉันดูอยากรู้อยากเห็นและ BAM! พวกเขาติดยาเสพติด:

แล้วฉันก็จะพูดถึงประเด็นต่าง ๆ เช่นคำตอบก่อนหน้านี้ แต่ฉันคิดว่ามันสำคัญที่จะต้องมีบริบทเช่นกันตามที่ JB King กล่าว ASP.NET ASP.NET MVC เป็นต้น