MVC​ ​คือ​อะไร​ ​และ​ ​Model​,​ ​View​,​ ​Controller​ ​ทำงาน​ร่วม​กัน​อย่างไร

MVC (Model–View–Controller) เป็นรูปแบบแยกหน้าที่ของแอป: Model แทนข้อมูลและกฎที่เกี่ยวข้อง View นำเสนอข้อมูล และ Controller รับการกระทำแล้วเลือกวิธีตอบ รูปแบบนี้ช่วยไม่ให้โค้ดแสดงผลกับกฎธุรกิจปะปนกัน แต่รายละเอียดของ MVC อาจต่างตาม Framework

ลำดับการทำงานในเว็บ

เมื่อผู้ใช้เปิดหน้ารายการ Route ส่ง Request ไป Controller, Controller ขอข้อมูลผ่าน Model หรือส่วนบริการ แล้วเลือก View ให้แสดงผล เมื่อส่งฟอร์ม Controller รับข้อมูล ตรวจตามขอบเขต และสั่งงานที่เหมาะสม ข้อควรระวังคืออย่าให้ Controller กลายเป็นที่รวมกฎธุรกิจทุกอย่างจนแก้และทดสอบยาก

ภาพที่ 1: MVC แยกการรับคำขอ การจัดกฎ/ข้อมูล และการแสดงผลให้มีหน้าที่ชัด

ตัวอย่างสมมติ: ระบบรายการสินค้า

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

MVC ต่างจาก Layered Architecture หรือไม่

MVC มักอธิบายการแยกงานเกี่ยวกับการโต้ตอบและการนำเสนอ ส่วน Layered Architecture อธิบายชั้นความรับผิดชอบของแอปกว้างกว่า ระบบหนึ่งอาจใช้ MVC ในชั้นเว็บและใช้ Service/Repository ภายในได้ จึงไม่ใช่ตัวเลือกที่ต้องเลือกอย่างใดอย่างหนึ่งเสมอ

สำหรับรายงาน

ยกหนึ่ง Request แล้วระบุว่า Model, View, Controller ใดทำอะไร พร้อมข้อจำกัดของ Framework ที่อ้างอิง หากระบบเป็น API ที่ส่ง JSON ไม่มี View แบบหน้าเว็บ ควรอธิบายการประยุกต์ใช้ให้ตรงระบบจริง ไม่คัดภาพ MVC มาวางโดยไม่ตรงงาน

อ่าน Layered Architecture หรือดู บริการ Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ เส้นทาง Request ผ่าน Controller ไป Model แล้วแสดง View ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

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

แหล่งข้อมูลประกอบ

• Microsoft Learn: Overview of ASP.NET Core MVC — บทบาท Model, View และ Controller