ตัวแบบ–มุมมอง–ตัวควบคุม

จากวิกิพีเดีย สารานุกรมเสรี
(เปลี่ยนทางจาก MVC)
แผนภาพของการโต้ตอบภายในรูปแบบ MVC

ตัวแบบ–มุมมอง–ตัวควบคุม (อังกฤษ: Model–view–controller) หรือเรียกย่อว่า MVC เป็นแบบแผนการออกแบบซอฟต์แวร์[1] ที่ใช้กันทั่วไปสำหรับการพัฒนาส่วนต่อประสานกับผู้ใช้ที่แบ่งตรรกะของโปรแกรมที่เกี่ยวข้องออกเป็นสามองค์ประกอบที่เชื่อมต่อถึงกัน องค์ประกอบเหล่านี้คือการแสดงข้อมูลภายใน (ตัวแบบ) อินเทอร์เฟซ (มุมมอง) ที่นำเสนอข้อมูลและรับข้อมูลจากผู้ใช้ และซอฟต์แวร์ตัวควบคุม ที่เชื่อมโยงทั้งสอง[2][3]

เดิมใช้สำหรับส่วนติดต่อผู้ใช้แบบกราฟิกบนเดสก์ท็อป (GUI) แต่ต่อมารูปแบบนี้ก็ได้รับความนิยมในการออกแบบโปรแกรมประยุกต์บนเว็บด้วย[4] ภาษาโปรแกรมยอดนิยมมีเฟรมเวิร์ก MVC ที่อำนวยความสะดวกในการใช้งานรูปแบบนี้

ความเป็นมา[แก้]

หนึ่งในข้อมูลเชิงลึกที่สำคัญในการพัฒนาส่วนต่อประสานผู้ใช้แบบกราฟิกในช่วงแรก MVC กลายเป็นหนึ่งในแนวทางแรก ๆ ในการอธิบายและใช้งานโครงสร้างซอฟต์แวร์ในแง่ของความรับผิดชอบ [5]

Trygve Reenskaug สร้าง MVC ในขณะที่ทำงานกับ Smalltalk -79 ในฐานะนักวิทยาศาสตร์รับเชิญที่ Xerox Palo Alto Research Center (PARC) ในช่วงปลายทศวรรษ 1970[6][7][8]: 330  เขาต้องการรูปแบบที่สามารถใช้เพื่อจัดโครงสร้างโปรแกรมใดๆ ที่ผู้ใช้โต้ตอบกับชุดข้อมูลขนาดใหญ่และซับซ้อน การออกแบบของเขาในตอนแรกมีสี่ส่วน: ตัวแบบ มุมมอง สิ่งของ และบรรณาธิการ หลังจากหารือกับนักพัฒนา Smalltalk คนอื่นๆ แล้ว เขาและคนอื่นๆ ในกลุ่มก็ตกลงเปลี่ยนเป็นตัวแบบ มุมมอง และตัวควบคุมแทน [6]

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

Smalltalk-80 รองรับเวอร์ชันของ MVC ที่พัฒนามาจากเวอร์ชันนี้ [6] โดยจัดให้มีคลาสนามธรรมคือ view และ controller รวมถึงคลาสย่อยที่เป็นรูปธรรมต่างๆ ของแต่ละคลาสที่แสดงถึงวิดเจ็ตทั่วไปที่แตกต่างกัน ในรูปแบบนี้ View แสดงถึงวิธีการแสดงข้อมูลแก่ผู้ใช้ และ controller แสดงถึงวิธีการบางอย่างที่ผู้ใช้โต้ตอบกับมุม view นอกจากนี้ view ยังเชื่อมโยงกับตัวแบบวัตถุด้วย แต่โครงสร้างของวัตถุนั้นขึ้นอยู่กับโปรแกรมเมอร์โปรแกรมประยุกต์ สภาพแวดล้อม Smalltalk-80 ยังมี "MVC Inspector" ซึ่งเป็นเครื่องมือพัฒนาสำหรับการดูโครงสร้างของตัวแบบ มุมมอง และตัวควบคุมที่กำหนดเคียงข้างกัน[9]

ในปี 1988 บทความใน The Journal of Object Technology (JOT) โดยอดีตพนักงาน PARC สองคน นำเสนอ MVC ว่าเป็น "กระบวนทัศน์และวิธีการเขียนโปรแกรม" ทั่วไปสำหรับนักพัฒนา Smalltalk-80 อย่างไรก็ตาม ผังของพวกเขาแตกต่างไปจากผังของ Reenskaug และคณะ และผังของหนังสืออ้างอิง Smalltalk-80 พวกเขากำหนดมุมมองว่าครอบคลุมความต้องการด้านกราฟิก โดยตัวควบคุมจะเป็นวัตถุที่เป็นนามธรรมและมองไม่เห็นโดยทั่วไป ซึ่งรับอินพุตจากผู้ใช้และโต้ตอบกับหนึ่งหรือหลายมุมมองและมีเพียงตัวแบบเดียวเท่านั้น [10]

รูปแบบ MVC ได้รับการพัฒนาในเวลาต่อมา [11] ก่อให้เกิดสำเนียงต่างๆ เช่น hierarchical model–view–controller (HMVC), model–view–adapter (MVA), model–view–presenter (MVP), model–view–viewmodel (MVVM) และอื่นๆ ที่ปรับ MVC ให้เข้ากับบริบทที่แตกต่างกัน

การใช้รูปแบบ MVC ในโปรแกรมประยุกต์บนเว็บเพิ่มขึ้นหลังจากการเปิดตัวWebObjects ของ NeXT ในปี 1996 ซึ่งเดิมเขียนด้วย Objective-C (ซึ่งยืมมาจาก Smalltalk เป็นจำนวนมาก) และช่วยบังคับใช้หลักการ MVC ต่อมา รูปแบบ MVC ได้รับความนิยมจากนักพัฒนา Java เมื่อ WebObjects ถูกย้ายไปยัง Java เฟรมเวิร์กรุ่นต่อมาสำหรับ Java เช่น Spring (เปิดตัวในเดือนตุลาคม 2002) ยังคงสานต่อความสัมพันธ์อันแน่นแฟ้นระหว่าง Java และ MVC

ในปี 2003 Martin Fowler ได้ตีพิมพ์ Patterns of Enterprise Application Architecture ซึ่งนำเสนอ MVC เป็นรูปแบบที่ "input controller" ได้รับการร้องขอ ส่งข้อความที่เหมาะสมไปยังวัตถุตัวแบบรับการตอบสนองจากวัตถุตัวแบบ และส่งการตอบสนองไปยัง มุมมองที่เหมาะสมสำหรับการแสดงผล[8]: 56  > ซึ่งใกล้เคียงกับแนวทางที่ดำเนินการโดยเฟรมเวิร์กแอปพลิเคชันเว็บ Ruby on Rails (สิงหาคม 2004) ซึ่งมีไคลเอ็นต์ส่งคำขอไปยังเซิร์ฟเวอร์ผ่านมุมมองในเบราว์เซอร์ คำขอเหล่านี้ได้รับการจัดการโดยตัวควบคุมบนเซิร์ฟเวอร์ และตัวควบคุม สื่อสารกับวัตถุโมเดลที่เหมาะสม[12] เฟรมเวิร์ก Django (กรกฎาคม 2005 สำหรับ Python ) หยิบยก "มุมมองแม่แบบตัวแบบ" (model template view หรือ MTV) ที่คล้ายกันมาใช้ ซึ่งมุมมองจะดึงข้อมูลจากตัวแบบและส่งผ่านไปยังแม่แบบเพื่อแสดงผล[13] ทั้ง Rails และ Django เปิดตัวโดยเน้นไปที่การ deploy ได้รวดเร็ว ซึ่งเพิ่มความนิยมของ MVC นอกเหนือไปจากสภาพแวดล้อมองค์กรแบบเดิม (ซึ่งได้รับความนิยมมายาวนาน)

องค์ประกอบ[แก้]

ตัวแบบ[แก้]

องค์ประกอบตรงกลางของรูปแบบ เป็นโครงสร้างข้อมูลแบบพลวัตของโปรแกรมประยุกต์ โดยไม่ขึ้นอยู่กับอินเทอร์เฟซผู้ใช้[14] โดยจะจัดการข้อมูล ตรรกะ และกฎของแอปพลิเคชันโดยตรง ใน Smalltalk-80 การออกแบบประเภทตัวแบบนั้นขึ้นอยู่กับโปรแกรมเมอร์ทั้งหมด[15] ด้วย WebObjects, Rails และ Django โดยทั่วไปประเภทตัวแบบจะแสดงถึงตารางในฐานข้อมูลของโปรแกรมประยุกต์[16][17][18]

มุมมอง[แก้]

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

ใน Smalltalk-80 มุมมองเป็นเพียงการแสดงตัวแบบด้วยภาพ และไม่รองรับอินพุตของผู้ใช้[19] ด้วย WebObjects มุมมองจะแสดงองค์ประกอบอินเทอร์เฟซผู้ใช้ที่สมบูรณ์ เช่น เมนูหรือปุ่ม และรับอินพุตจากผู้ใช้[20] อย่างไรก็ตาม ทั้งใน Smalltalk-80 และ WebObjects มุมมองต่างๆ มีไว้เพื่อวัตถุประสงค์ทั่วไปและสามารถประกอบได้[21][22]

ใน Rails และ Django เทมเพลต HTML ทำหน้าที่เป็นมุมมอง ดงนั้นในรูปแบบของพวกเขา มุมมองจะระบุอินเทอร์เฟซผู้ใช้ในเบราว์เซอร์ แทนที่จะแสดงวิดเจ็ตอินเทอร์เฟซผู้ใช้โดยตรง[23][24] (Django เลือกที่จะเรียกวัตถุประเภทนี้ว่า "เทมเพลต" ด้วยเหตุนี้[25] ) แนวทางนี้ไม่ค่อยเน้นที่มุมมองขนาดเล็กที่ประกอบได้ มุมมองใน Rails ทั่วไปมีความสัมพันธ์แบบหนึ่งต่อหนึ่งกับการกระทำของตัวควบคุม[26]

มุมมองใน Smalltalk-80 สื่อสารกับทั้งตัวแบบและตัวควบคุม[27] ในขณะที่ WebObjects มุมมองจะพูดคุยกับตัวควบคุมเท่านั้น จากนั้นจะพูดคุยกับโมเดล[28] ด้วย Rails และ Django ตัวควบคุม/มุมมองจะใช้มุมมอง/เทมเพลตเมื่อเตรียมการตอบสนองต่อไคลเอนต์[29] [30]

ตัวควบคุม[แก้]

ตัวควบคุมรับอินพุตและแปลงเป็นคำสั่งสำหรับตัวแบบหรือมุมมอง[31]

ตัวควบคุมใน Smalltalk-80 จัดการเหตุการณ์อินพุตของผู้ใช้ เช่น การกดปุ่มหรือการเคลื่อนไหวของเมาส์[32] ในช่วงเวลาใดก็ตาม ตัวควบคุมแต่ละตัวจะมีมุมมองและตัวแบบที่เกี่ยวข้องกันหนึ่งรายการ แม้ว่ตัวแบบวัตถุหนึ่งอาจ"ได้ยิน"จากตัวควบคุมหลายตัวที่แตกต่างกัน ตัวควบคุมเพียงตัวเดียวเท่านั้นคือตัวควบคุม "แอคทีฟ" สามารถรับอินพุตจากผู้ใช้ในเวลาใดเวลาหนึ่ง วัตถุตัวจัดการหน้าต่างส่วนกลางมีหน้าที่รับผิดชอบในการตั้งค่าตัวควบคุมที่ใช้งานอยู่ในปัจจุบัน หากอินพุตของผู้ใช้แจ้งให้เปลี่ยนตัวแบบ ตัวควบคุมจะส่งสัญญาณให้ตัวแบบเปลี่ยน แต่ตัวแบบจะรับผิดชอบในการบอกมุมมองให้อัปเดต[33]

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

ใน Rails คำขอที่มาถึงโปรแกรมประยุกต์บนเซิร์ฟเวอร์จากไคลเอนต์จะถูกส่งไปยัง "เราเตอร์" ซึ่งเชื่อมโยงคำขอกับวิธีการเฉพาะของตัวควบคุมเฉพาะ ภายในวิธีการนั้น ตัวควบคุมจะโต้ตอบกับข้อมูลคำขอและตัวแบบวัตถุที่เกี่ยวข้อง และเตรียมการตอบสนองโดยใช้มุมมอง ตามอัตภาพ แต่ละมุมมองจะมีตัวควบคุมที่เกี่ยวข้องกัน ตัวอย่างเช่น หากโปรแกรมประยุกต์มีมุมมอง client โดยทั่วไปก็จะมีตัวควบคุม Clients ที่เกี่ยวข้องเช่นกัน อย่างไรก็ตาม นักพัฒนาสามารถสร้างตัวควบคุมประเภทอื่นได้อย่างอิสระหากต้องการ[35]

Django เรียกวัตถุที่มีบทบาทนี้ว่า "มุมมอง" แทนที่จะเป็นตัวควบคุม[30] มุมมอง Django เป็นฟังก์ชันที่รับคำขอทางเว็บและส่งคืนการตอบกลับทางเว็บ อาจใช้เทมเพลตเพื่อสร้างการตอบกลับ[36]

การโต้ตอบ[แก้]

นอกเหนือจากการแบ่งโปรแกรมประยุกต์ออกเป็นส่วนประกอบเหล่านี้แล้ว การออกแบบ MVC ยังกำหนดการโต้ตอบระหว่างส่วนประกอบเหล่านั้นด้วย[37]

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

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

ดูเพิ่ม[แก้]

อ้างอิง[แก้]

  1. ↑ "The Principles of Clean Architecture by Uncle Bob Martin". YouTube.
  2. ↑ Reenskaug, Trygve; Coplien, James O. (20 March 2009). "The DCI Architecture: A New Vision of Object-Oriented Programming". Artima Developer. คลังข้อมูลเก่าเก็บจากแหล่งเดิมเมื่อ 23 March 2009. สืบค้นเมื่อ 3 August 2019. More deeply, the framework exists to separate the representation of information from user interaction.
  3. ↑ Burbeck (1992): "... the user input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object."
  4. ↑ Davis, Ian. "What Are The Benefits of MVC?". Internet Alchemy. สืบค้นเมื่อ 2016-11-29.
  5. ↑ Model–View–Controller History. C2.com (2012-05-11). Retrieved on 2013-12-09.
  6. ↑ 6.0 6.1 6.2 6.3 Notes and Historical documents from Trygve Reenskaug, inventor of MVC.
  7. ↑ "A note on DynaBook requirements", Trygve Reenskaug, 22 March 1979, SysReq.pdf.
  8. ↑ 8.0 8.1 Fowler, Martin (2003). Patterns of Enterprise Application Architecture. Pearson Education, Inc. ISBN 0-321-12742-0.
  9. ↑ Goldberg, Adele (1984). Smalltalk-80: The Interactive Programming Environment. Addison-Wesley. ISBN 0-201-11372-4.
  10. ↑ Krasner, Glenn E.; Pope, Stephen T. (Aug–Sep 1988). "A cookbook for using the model–view controller user interface paradigm in Smalltalk-80". The Journal of Object Technology. SIGS Publications. 1 (3): 26–49. Also published as "A Description of the Model–View–Controller User Interface Paradigm in the Smalltalk-80 System" (Report), ParcPlace Systems; Retrieved 2012-06-05.
  11. ↑ The evolution of MVC and other UI architectures from Martin Fowler.
  12. ↑ "Ruby on Rails Guides". สืบค้นเมื่อ March 19, 2022.
  13. ↑ "Django FAQ: Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names?". สืบค้นเมื่อ March 19, 2022.
  14. ↑ Burbeck, Steve (1992) Applications Programming in Smalltalk-80:How to use Model–View–Controller (MVC)
  15. ↑ LaLonde, Wilf R.; Pugh, John R. (1991). Inside Smalltalk. U.S.A.: Prentice-Hall Inc. p. 8. ISBN 0-13-467309-3. The model can be any object without restriction.
  16. ↑ WebObjects System Overview (PDF). Cupertino, CA: Apple Computer, Inc. May 2001. p. 28. In WebObjects, a model establishes and maintains a correspondence between an enterprise object class and data stored in a relational database.
  17. ↑ "Active Record Basics". Rails Guides. สืบค้นเมื่อ October 27, 2022. This will create a Product model, mapped to a products table at the database.
  18. ↑ "Models". Django Documentation. สืบค้นเมื่อ October 27, 2022. Generally, each model maps to a single database table.
  19. ↑ LaLonde, Wilf R.; Pugh, John R. (1991). Inside Smalltalk. U.S.A.: Prentice-Hall Inc. p. 8. ISBN 0-13-467309-3. The view is responsible for providing a visual representation of the object.
  20. ↑ WebObjects System Overview (PDF). Cupertino, CA: Apple Computer, Inc. May 2001. p. 28. View objects represent things visible on the user interface (windows, for example, or buttons).
  21. ↑ LaLonde, Wilf R.; Pugh, John R. (1991). Inside Smalltalk. U.S.A.: Prentice-Hall Inc. p. 8. ISBN 0-13-467309-3. [MVC] permits views to be used as parts for assembly into larger units; new kinds of views can be constructed using existing views as subviews.
  22. ↑ WebObjects System Overview (PDF). Cupertino, CA: Apple Computer, Inc. May 2001. p. 28. View objects tend to be very reusable and so provide consistency between applications.
  23. ↑ "Action View Overview". Rails Guides. สืบค้นเมื่อ October 27, 2022. Action View templates are written using embedded Ruby in tags mingled with HTML.
  24. ↑ "Templates". Django Documentation. สืบค้นเมื่อ October 27, 2022. A template contains the static parts of the desired HTML output as well as some special syntax describing how dynamic content will be inserted.
  25. ↑ "Django FAQ: Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names?". สืบค้นเมื่อ October 27, 2022.
  26. ↑ "Action View Overview". Rails Guides. สืบค้นเมื่อ October 27, 2022. Typically, the views share their name with the associated controller action...
  27. ↑ LaLonde, Wilf R.; Pugh, John R. (1991). Inside Smalltalk. U.S.A.: Prentice-Hall Inc. p. 9. ISBN 0-13-467309-3. ...the view knows explicitly about the model and the controller.
  28. ↑ WebObjects System Overview (PDF). Cupertino, CA: Apple Computer, Inc. May 2001. p. 28. Acting as a mediator between Model objects and View objects in an application is a Controller object.
  29. ↑ "Action View Overview". Rails Guides. สืบค้นเมื่อ October 27, 2022. In Rails, web requests are handled by action controller and action view. Typically, action controller is concerned with communicating with the database and performing CRUD actions where necessary. Action View is then responsible for compiling the response.
  30. ↑ 30.0 30.1 "Django FAQ: Django appears to be a MVC framework, but you call the Controller the "view", and the View the "template". How come you don't use the standard names?". สืบค้นเมื่อ October 27, 2022. In Django, a 'view' describes which data is presented, but a view normally delegates to a template, which describes how the data is presented. อ้างอิงผิดพลาด: ป้ายระบุ <ref> ไม่สมเหตุสมผล มีนิยามชื่อ "djangoviewtemplfaq" หลายครั้งด้วยเนื้อหาต่างกัน
  31. ↑ Simple Example of MVC (Model–View–Controller) Architectural Pattern for Abstraction
  32. ↑ LaLonde, Wilf R.; Pugh, John R. (1991). Inside Smalltalk. U.S.A.: Prentice-Hall Inc. p. 8. ISBN 0-13-467309-3. The controller is responsible for interfacing between the user and the model/view. It interprets keyboard characters along with mouse movements and clicking.
  33. ↑ LaLonde, Wilf R.; Pugh, John R. (1991). Inside Smalltalk. U.S.A.: Prentice-Hall Inc. p. 11. ISBN 0-13-467309-3.
  34. ↑ WebObjects System Overview (PDF). Cupertino, CA: Apple Computer, Inc. May 2001. p. 28.
  35. ↑ "Action View Overview". Rails Guides. สืบค้นเมื่อ October 27, 2022. Typically, the views share their name with the associated controller action...
  36. ↑ "Writing views". Django Documentation. สืบค้นเมื่อ October 27, 2022.
  37. ↑ Buschmann, Frank (1996) Pattern-Oriented Software Architecture.
  38. ↑ Gamma, Erich et al. (1994) Design Patterns
  39. ↑ Moore, Dana et al. (2007) Professional Rich Internet Applications: Ajax and Beyond: "Since the origin of MVC, there have been many interpretations of the pattern. The concept has been adapted and applied in very different ways to a wide variety of systems and architectures."

บรรณานุกรม[แก้]

แม่แบบ:Design Patterns patterns

เข้าถึงจาก "https://th.wikipedia.org/w/index.php?title=ตัวแบบ–มุมมอง–ตัวควบคุม&oldid=11287884"