[นายข้าวโพดหวาน]

MVC เป็นเฟรมเวิร์คที่เกิดขึ้นมาในสมัย Smalltalk-80 เมื่อกว่ายี่สิบปีมาแล้ว โดยแยกออปเจคที่เก็บข้อมูล (model) ออปเจคที่แสดงข้อมูล (view) และออปเจคที่ติดต่อกับผู้ใช้ (controller) ออกจากกันอย่างชัดเจน การสื่อสารระหว่างออปเจ็คจะใช้ Observer pattern นั่นหมายความว่าตัวออปเจคที่ถูก observe จะแจ้งการเปลี่ยนแปลงที่เกิดขึ้นในตัวมันให้แก่ตัว observer ทุกตัวโดยไม่จำเป็นต้องรู้ว่าตัว observer แต่ละตัวเป็นใครหรือเป็นออปเจ็คของคลาสไหน ตราบใดที่คลาสนั้นimplement observer (หรือ listener) interface

การแยกออปเจคเหล่านี้ออกจากกันจะทำให้ง่ายต่อการแก้ไขโปรแกรม เช่น เราสามารถเปลี่ยน view จาก GUI เป็น HTML (รวมทั้ง jsp, aspx, php), WML หรือ text mode ได้โดยไม่ต้องแก้โมเดล หรือเราจะสนับสนุนหลายๆวิวพร้อมๆกัน เช่น ลูกค้าตลาดหุ้นแต่ละคนจะมีหน้าจอดูราคาหุ้นในตลาดหลักทรัพย์ แต่ละคนจะมีวิวของตัวเองและจะแสดงข้อมูลหลักทรัพย์เฉพาะที่ตัวเองสนใจ ในขณะที่ออปเจคโมเดลคือหลักทรัพย์ทั้งหมดในตลาด เป็นต้น



หลักการสำคัญ ก็คือ โมเดลจะไม่สามารถเรียกเมดธอดของวิวหรือคอนโทรลเลอร์โดยตรง เนื่องจากมันจะไม่มีตัวแปรเก็บออปเจคที่เป็นวิวหรือคอนโทรลเลอร์ โมเดลมีเพียงแต่ list ของออปเจคชนิด observer (วิวหรือคอนโทรลเลอร์ที่ implement observer interface) ที่เฝ้าสังเกตุการเปลี่ยนแปลงอยู่ ตัวโมเดลจะแจ้งการเปลี่ยนแปลงด้วยการส่ง event notification message ไปให้ observer ทุกๆตัว ถ้า observer นั้นเป็นวิวก็จะอัพเดปหน้าจอด้วยขอมูลใหม่ เป็นต้น ในทำนองเดียวกันตัววิวเองก็มองไม่เห็นคอนโทรลเลอร์ ไม่สามารถเรียกเมดธอดของคอนโทรลเลอร์ได้โดยตรง นอกจากจะส่ง event ไปให้คอนโทรลเลอร์ที่เป็น observer ของวิวนั้นๆ

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

มีผู้ดัดแปลง MVC ไปใช้หลายรูปแบบ เช่น Swing เรียก MVC2 บางรายใช้ Model-View-Presenter หรือไม่ก็ Model-User Interface แต่หลักการก็ยังคล้ายๆเดิม เพียงแตกต่างที่การติดต่อระหว่างโมเดล วิว คอนโทรลเลอร์ ว่าใครเป็นผู้แจ้งหรือตอบรับการเปลี่ยนแปลงเหตุการณ์ (event notification) หรือการรวม view กับ controller เข้าด้วยกัน รายละเอียดเพิ่มเติม รวมทั้งวิธีการเขียนโปรแกรมตามหลัก MVC คงต้องไปดูลิงค์ข้างล่างครับ

คอนเซ็ปของ MVC
http://java.sun.com/blueprints/patterns/MV...C-detailed.html
http://www.object-arts.com/EducationCentre...erviews/MVC.htm
http://www.cs.indian...ojects/mvc.html
เปรียบเทียบ Classical MVC กับ present MVC framework
http://www.holobloc....vc/classicl.htm

[jsapDB]

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

[นายข้าวโพดหวาน]

ไม่แน่ใจว่าคำว่าหลักการทั่วไปหมายถึงอะไร แค่ MVC เป็นหลักการที่ใช้ในการโปรแกรมเชิงวัตถุที่ออปเจคแต่ละตัวสามารถส่งแมสเสจถึงกันได้ การส่งแมสเสจอาจจะเป็นการเรียกเมดธอดแบบ synchronous call ที่ฝ่ายผู้ส่งต้องรอจนกว่าฝ่ายผู้รับประมวลผลข้อมูลเสร็จแล้วรีเทิร์น execution control กลับมา หรือเป็นแบบ asynchronous call ที่ฝ่ายผู้ส่งไม่ต้องรอ เมื่อผู้รับประมวลผลเสร็จจะเป็นผู้ notify กลับมาเอง

อาจารย์ผมเล่าให้ฟังว่า ต้นกำเนิดของ MVC มาจากนาย Trygve Reenskaug ในสมัยที่นาย Trygve หันมาจับภาษา Smalltalk ซึ่งเป็นภาษา pure OOP ที่พัฒนามาจาก Xerox โดยนาย Alan Kay ตัว Smalltalk มี IDE เป็นกราฟฟิค โดยตัว IDE เป็นวิวและมีออปเจค controller ที่คอยควบคุมวิวและติดต่อกับโมเดลซึ่งก็คือตัว Smalltalk environment (object ทั้งหมดใน Smalltalk, ตัวคอมไพเลอร์) เมื่อนาย Trygve คิดค้น MVC และมีผู้สนใจนำไปใช้พบว่าเป็นเฟรมเวิร์คที่ยืดหยุ่นช่วยทำให้การพัฒนาโปรแกรมขนาดใหญ
่ง่ายขึ้น แต่ละออปเจคในแต่ละส่วนไม่ผูกติดกันมากเกินไปทำให้สามารถแบ่งทีมพัฒนาแยกออกจากกันได
้ชัดเจน ก็เลยเอาหลักการนี้ไปใช้ในการพัฒนาโปรแกรมทางด้านอื่นๆจนกลายมาเป็นสถาปัตยกรรมที่ระ
บบระดับ enterprise นิยมอ้างถึง

ตัว Smalltalk เองเป็นภาษาที่ใช้หลักการของ untyped, bytecode, garbage collection และเทคนิคอื่นๆอีกมาก และมีมาตั้งแต่สมัยยี่สิบกว่าปีมาแล้ว ภาษาใหม่ๆในปัจจุบันได้ขอยืมเทคนิคเหล่านี้มาใช้และประสบความสำเร็จกันมากมาย ตัว Smalltalk เองปัจจุบันเป็นภาษาที่มีคนใช้กลุ่มเล็กๆในวงการการศึกษาและบริษัทกลุ่มเล็กๆ แต่คนในวงการเชิงวัตถุถือว่าภาษานี้เป็นตัวอย่างภาษาเชิงวัตถุที่สมบูรณ์ครับ

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

[lsomchai]

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

[นายข้าวโพดหวาน]

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

ภาษา Smalltalk เป็นภาษาแบบ interpretator แบบ untyped นั่นคือตัวแปรใน Smalltalk ไม่ต้องกำหนดชนิด ข้อมูลทุกอย่างจะเป็นออปเจค นั่นคือไม่มี primitive data type ดังนั้นเราไม่ต้องห่วงเรื่องการแปลงข้อมูลระหว่างออปเจคกับ primitive data type อย่างเช่นจาวา การ evaluate ชนิดของตัวแปรจะกระทำในระหว่าง interpret ตอน run time ในลักษณะนี้ Smalltalk จึงดูเหมือนเป็นภาษาเชิง scripting มากกว่าภาษาที่เป็นแบบ typed language

ตัว Smalltalk เองมี syntax ที่น้อยมาก และตัวภาษาเองครอบคลุมไปถึง IDE และ environment (smalltalk เรียกมันว่า image) ที่เก็บสถานะของออปเจ็คทุกตัวของระบบและที่ถูกสร้างขึ้นโดยคนเขียนโปรแกรม) การติดต่อระหว่งออปเจค จะใช้วิธีการส่งแมสเสจ เนื่องจากเราไม่จำเป็นต้องระบุชนิดของออปเจคที่เก็บไว้ในตัวแปร ดังนั้นมันมีโอกาสที่เราจะส่งแมสเสจที่ออปเจคนั้นไม่รู้จัก จะทำให้เกิด runtime exception ที่ชื่อว่า doesNotUnderstand ขึ้น

ภาษา Smalltalk จึงมีความยืดหยุ่นสูงมาก class library ทุกตัวใน smalltalk สามารถถูกดูซอร์สโค้ด แก้ ขยาย (extend) เปลี่ยนแปลงได้ตามต้องการภายใต้ object browser ของตัว smalltalk เอง ตัว GUI ก็มี window และ widget ของมันเองที่เอามาใช้ได้ง่าย และเนื่องจาก smalltalk คอยติดตามออปเจคที่ถูกสร้างขึ้นมาทั้งหมด ดังนั้นมันจึงสนับสนุนการทำ garbage collection ได้ในตัว การดีบักก็ทำได้ง่ายผ่าน object browser ของมันเอง เรียกว่าทำทุกอย่างได้ภายใต้ environment ของคุณเอง ข้อดีหลักๆอีกอันหนึ่งของ smalltalk คือการสนับสนุน block closure นั่นคือคุณสามารถผ่าน code block เป็นพารามิเตอร์ให้กับเมดธอด (smalltalk เรียก class method ว่า message selector) ใดๆก็ได้ แล้วโค้ดนั้นๆจะถูก interpret และประมวลผลในระหว่างรัน ซึ่งคอนเส็ปนี้ก็คล้ายๆกับ lamda closure ใน LISP นั่นเอง คอนเส็ปเรื่อง collections ของจาวาก็มีอยู่ใน smalltalk มากว่ายี่สิบปีแล้ว

คราวนี้ข้อเสียของ smalltalk ก็อยู่ที่ว่ามันเกิดเร็วไปหน่อยในยุคที่บริษัทส่วนใหญ่ยังใช้ภาษาโครงสร้างอยู่ ความยืดหยุ่นสูงของ smalltalk เลยทำให้การทำงานค่อนข้างช้า ในยุคสมัย 1980s เครื่องยังช้าและมีหน่วยความจำจำกัด เลยทำให้ smalltalk รันได้ดีเฉพาะเครื่องระดับ workstation ที่มี graphical window system ซึ่งในสมัยนั้นเครื่องคอมฯส่วนใหญ่ยังเป็น text mode อยู่ ดังนั้นตัว smalltalk เองจึงถูกใช้เฉพาะในโครงการวิจัยมหาลัยหรือองค์กรใหญ่ๆ และอีกข้อจำกัดหนึ่งคือตัวภาษานี้ค่อนข้างมีโลกส่วนตัว การติดต่อกับโปรแกรมภาษาอื่นๆหรือฐานข้อมูลอื่นจึงไม่เก่ง และสุดท้ายคือตัวภาษาอาจเข้าใจยากสำหรับผู้เริ่มต้น และการที่เป็นภาษาแบบ interpretater เลยทำให้ไม่มีโอกาสตรวจหาบั๊กในช่วงพัฒนา (เนื่องจากไม่มี compiler ที่จะตรวจหา compile-time error นั่นเอง) คนที่ศึกษา smalltalk อย่างไม่จริงจัง จะรู้สึกว่ามันซับซ้อนและยากในการหาบั๊ก

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

ที่พูดมาทั้งหมดเป็นเพียงแค่ผิวเผินของ smalltalk เนื่องจากผมเคยเรียนมานานแล้ว และก็ไม่ได้ใช้ภาษานี้เป็นหลัก และก็เขียนเท่าที่นึกได้ตอนนี้ ถ้าขาดตกอะไรใครต้องการเสริม ช่วยเพิ่มเติมได้เลยครับ
[/list]

[Bomber]

พอดีผมไปเจอรูปนี้ที่ Web Site msdn.microsoft.com เห็นว่าดูเข้าใจง่ายดีเลยเอามาแชร์ครับ

[plynoi]

ขอถามหน่อยครับ
ผมเคยได้ยินมาเกี่ยวกับ MVC ในเชิงเวบของ java
มีหลายๆความเห็นบอกว่าให้พัฒนาโดยแยก
Model=Servlet
View=JSP
Control=Bean หรือ Class อื่นๆ
ซึ่งผมได้ลองพัฒนาเองแบบแล้ว(ยังไม่ถึงขั้นใช้ Struts นะครับ)
พบว่า พัฒนาได้ยากมากๆ ในการที่จะแยก Servlet หรือ Class/Bean ต่างๆออกจากกัน และตอนไปวางพวกข้อมูลต่างๆใน JSP อีก(สำหรับผมนะ)
ไม่ทราบว่าพอมีเวบ หรือแนวทางเป็นตัวอย่างรึเปล่าครับ
หรือว่าจะใช้ struts ไปเลยครับ

[Sand]

เอ ผมเข้าใจผิดไปเหรอครับผมก็นึกว่า
Model คือ Business logic หรือ Bean
View คือ Presentation หรือ Struts Tag,JSP Tag,HTML
Controller คือ Servlet หรือ Action,ActionMapping & XML Config

[Oop Rookie]

Sand, on Jun 30 2004, 08:08 AM, said:

Model คือ Business logic หรือ Bean
View คือ Presentation หรือ Struts Tag,JSP Tag,HTML
Controller คือ Servlet หรือ Action,ActionMapping & XML Config

ผมก็เข้าใจแบบคุณ sand ครับ เอะหรือยังไง

[Bomber]

Sand, on Jun 30 2004, 08:08 AM, said:

เอ ผมเข้าใจผิดไปเหรอครับผมก็นึกว่า
Model  คือ  Business  logic หรือ Bean 
View  คือ  Presentation หรือ Struts Tag,JSP Tag,HTML
Controller คือ  Servlet หรือ  Action,ActionMapping & XML Config

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

อย่าง model ที่ผม post ก่อนหน้าก็เป็นการแจกแจงรายละเอียดของงานในแต่ละส่วนที่จะต้องทำ อาจจะไม่ต้องทำทั้งหมดแต่ลักษณะงานควรอยู่ใน scope นี้คือ controller จะทำหน้าที่ Filter Request, Extract Data, Map request to command, Invoke command to handler request สองอันหลังอาจจะคิดว่าเป็นการ map request เข้ากับ model และ view ที่จะต้องใช้ได้ครับ ส่วนตัว model จะทำหน้าที่ organize work for request, perform operation, retrive data ซึ่งก็คือส่วนทำงานจริงของตัว request นั้นๆ สุดท้าย view จะทำหน้าที่ determine page to display, format page for display ก็คือส่วนของการนำข้อมูลที่ได้จาก model มาแสดงผลนั่นเอง

ในกรณีของคุณ plynoi ถ้าไม่ใช้ struts ก็สามารถออกแบบ web app เป็น mvc ได้ แต่ก็จะมีปัญหาเรื่อง maintain servlet ในส่วนของ controller ที่มันจะมีมากและแก้ไขลำบาก เพราะต้องไปแก้ไขที่ web.xml ด้วย นอกจากนี้จะเปรือง resource มากกว่าตัว struts เนื่องจากการมี servlet ใหม่หมายถึงจะมี instance สำหรับทุก controller ซึ่ง struts จะมี controller กลางรับ request เดียวแล้ว เราเขียน Action class รับการ invoke จากตัว main controller ของ struts อีกทีครับ ทำให้ใช้ resource น้อยกว่า

แต่ขอออกตัวไว้ก่อนว่าผมไม่ได้เป็นผู้เชี่ยวชาญด้าน struts นะครับอาจจะเข้าใจผิดบ้าง ก็ขอ VC ท่านอื่นแก้ไขหรือเสริมตามสมควรด้วยครับ

[plynoi]

ขอบคุณคุณ Bomber มากเลยครับ
ว่าแต่ขออภัยด้วยครับ
เรื่อง
Model=Servlet,Control=Bean นั่นผมพิมพ์ผิดเองแหละครับ จริงๆเป็นแบบที่ทุกคนเข้าใจกันแหละครับว่า Model=Bean/Class และ Control=Servlet

Quote

อย่าง model ที่ผม post ก่อนหน้าก็เป็นการแจกแจงรายละเอียดของงานในแต่ละส่วนที่จะต้องทำ อาจจะไม่ต้องทำทั้งหมดแต่ลักษณะงานควรอยู่ใน scope นี้คือ controller จะทำหน้าที่ Filter Request, Extract Data, Map request to command, Invoke command to handler request สองอันหลังอาจจะคิดว่าเป็นการ map request เข้ากับ model และ view ที่จะต้องใช้ได้ครับ ส่วนตัว model จะทำหน้าที่ organize work for request, perform operation, retrive data ซึ่งก็คือส่วนทำงานจริงของตัว request นั้นๆ สุดท้าย view จะทำหน้าที่ determine page to display, format page for display ก็คือส่วนของการนำข้อมูลที่ได้จาก model มาแสดงผลนั่นเอง

ขอถามต่ออีกนิดครับ
ตอนนี้ผมใช้ Servlet ในการจัดการว่า จาก jsp นี้จะไปทำอะไรต่อ โดยจะเรียกใช้ Class หรือ Bean อื่นๆในการ จัดการข้อมูลที่ได้มาจาก jsp นั้น แล้วก็ใช้ Servlet ตัวเดียวกันส่งข้อมูลไปยัง jsp ที่เป็นผลลัพท์ซึ่งอาจจะส่งทาง session หรือว่าใช้ setAttribute ไป หรือใช้ bean แล้วใน jsp ใช้ <jsp:usebean> ครับ ตามที่คุณ bomber บอกมา คุณ bomber ใช้ model เป็นตัวส่งข้อมูลใน view นั้นทำอย่างไรครับ และการส่งข้อมูลไปยัง View นั้นวิธีไหนที่ดีที่สุดครับ

This post has been edited by plynoi: 30 June 2004 - 11:35 AM

[Bomber]

ตัว Model ที่ผมใช้ ผมจะมี Model อยู่ 2 ชนิด คือ Model ที่ทำงานจริง และ Model ที่เก็บผลลัพธ์ของงาน วิธีการคือเมื่อ Request เข้ามาที่ Controller คือ Servlet ตัว servlet ก็จะเรียกใช้ Model (Worker) ที่เกี่ยวกับ Request นั้น โดยเมื่อทำงานเสร็จ Controller เองจะได้ Model อีกตัว (Data) ออกมา เพื่อ setAttribute ให้ Request จากนั้นก็ forward request ไปยัง View ของ request นี้ซึ่งก็คือ jsp นั่นเอง ตัว Jsp ก็นำ data มาแสดงผล รวมถึงกำหนดรูปแบบที่จะใช้แสดง เช่น data format, number format ครับ

ผมเห็นหลายๆคนชอบจัดการ format ใน controller หรือไม่ก็ใน model ซึ่งผมมองว่าไม่ค่อยดีนัก เพราะจริงตัวที่จัดการเรื่องแสดงผลควรจะอยู่ที่ view เท่านั้น ซึ่งถ้าการแสดงผลทุกอย่างอยู่ที่ view เราจะสามารถแก้ไขโปรแกรมของเราในอนาคตได้ง่ายมาก เพราะมันชัดเจนดี

[plynoi]

ขอบคุณมากครับ อธิบายได้กระจ่างเลยครับ ได้แนวทางการ Coding เลยครับ

ว่าแต่ขอถามต่ออีกนิด(อีกแล้ว )
เราควรที่จะใช้ 1 Control สำหรับทั้งระบบเลยรึเปล่าครับ เพราะตอนนี้ผมใช้ 1 Servlet ต่อ 1 jsp เลยทีเดียว
และถามอีกอย่างครับ ใน MVC นี่ การใช้ Tag Bean อย่างเช่น <jsp:usebean> นี่เหมาะสมรึเปล่าครับ

[Bomber]

ตามหลักแล้วควรมี servlet เดียวครับ แต่การทำ servlet เดียวนั้นยากพอสมควร ซึ่งนั่นหมายถึงต้องทำตัวแยกความแตกต่างของ request และตัว mapping เรียกใช้ model และ view ซึ่งวิธีนี้เราเรียกว่า Front Controller ครับ นั่นก็คือ Struts นั่นเอง

Struts จะมี Front Controller ให้เราแล้วเราก็ทำการ Extend เป็น Action Class ย่อยๆ และมี Mapping เป็น xml ซึ่งทำให้ง่ายต่อการ develop มากครับ

เพราะฉะนั้นถ้าลองเขียนเล่นทดลองตัว MVC ทำเป็น servlet แยกทุก request ก็ได้ครับง่ายดี เอาให้เข้าใจ concept ของการ design แบบ MVC ก่อนครับ

ลองอ่าน Front Controller ดูก็ได้ครับ ถึงจะเป็นของ Microsoft แต่ก็หลายๆอย่างก็สามารถประยุกต์ใช้กับ J2EE ได้เหมือนกัน

This post has been edited by Bomber: 30 June 2004 - 03:34 PM

[plynoi]

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