หนึ่งอย่างที่น่าสนใจของ Rails คือการกำหนดข้อกำหนดต่างๆ(Convention over Configuration) ในการสร้าง web application แต่น่าแปลก ข้อกำหนดเหล่านี้ กลับทำให้การทำ web application นั้น ง่ายขึ้น มาดูกัน ว่าทำไม

MVC - Model, View, and Controller

ย้อนกลับไปปี 1979 คุณ Trygve Reenskaug ได้มาพร้อมกับสถาปัตยกรรมตัวใหม่สำหรับการพัฒนา web applciation ในสิ่งที่เขาออกแบบมา มันจะถูกแตกออกเป็น 3 ส่วน คือ models, views, และ controller

มาดูที่ตัวแรกก่อน

Model

เป็นตัวเก็บสถานะของ web app ของเรา บางทีสถานะเหล่านั้นเกิดขึ้นแป๊บเดียว แต่บางทีมันก็เกิดอย่างถาวร เราก็จะเก็บไว้ใน model นี้ไม่ได้ละ ส่วนใหญ่จะเก็บใน database กัน model นี้ มันมีอะไรที่มากกว่าข้อมูล มันจะไปบังคับเงื่อนไขต่างๆที่เราจะกระทำกับข้อมูล เช่น ถ้าหากส่วนลดมันไม่ควรจะถูกลดใน order ที่มีมูลค่าน้อยกว่า 20 หน่วย model นี้ก็จะไปบังคับข้อกำหนดนี้ให้ทำงาน(เราต้องเขียนให้มันทำงานนะ) สิ่งต่างๆ ที่เรากำหนดใน model นี้ จะทำให้เรามั่นใจได้ว่าไม่มีสิ่งอื่นๆ มาทำให้ข้อมูลเราผิดพลาด ดังน้ัน ตัว model มันจึงเหมือนที่เก็บข้อมูล และยังเป็นตัวกลั่นกรองความถูกต้องอีกด้วย

View

เป็นตัวสร้างหน้าตาส่วนที่ไว้ติดต่อกับผู้ใช้ ปกติแล้วมันจะข้อมูลที่อยู่ใน model เช่น ในเว็บขายของ จะมีรายการของสินค้าต่างๆ แสดงอยู่ ซึ่งรายการสินค้าเหล่านี้ มันจะสามารถเข้าถึงทาง model ได้(เอาสินค้าแต่ละชิ้นจาก model มาจัดเป็นรายการในหน้าเว็บ) แต่ view นี้ มันจะเป็นการแสดงที่เข้าถึงรายการสินค้าและจัดรูปแบบต่างๆ จาก model(จัดสินค้าแต่ละชิ้นเป็นรายการสินค้าก่อนใน model แล้วค่อยมาแสดงในหน้าเว็บ) ถึงแม้ว่า view จะสามารถแสดงได้ว่าจะให้คนที่เข้ามาในเว็บทำการใส่ข้อมูลต่างๆ ได้มาก หลายวิธี แต่ตัวมันเอง จะไม่ทำอะไรกับข้อมูลทีี่เข้ามา ควรจะสั่งให้อ่านอย่างเดียว และ View จะถูกทำงานเพียงหนึ่งครั้งหลังจากที่ข้อมูลถูกแสดงแล้ว อาจจะมี view หลายๆตัว ที่เข้าถึง model ตัวเดียวกันได้ เช่น ในเว็บขายของ หน้า catalog จะทำการแสดงสินค้าต่างๆ แต่ในหน้า admin ก็จะทำการเพิ่มสินค้า ซึ่งทั้งสองหน้า จะเข้าถึง model ตัวเดียวกัน

Controller

เป็นตัวจัดการเว็บของเรา controller นี้ จะรับเหตุการณ์ต่างๆ จากหน้าเว็บ มาจัดการ ทำการติดต่อกับ model และแสดง view ที่เหมาะสมกับผู้ใช้

มาดูรูปอธิบายโครงสร้างของ MVC

MVC นี่ มันถูกตั้งใจให้เป็นแบบแผนของ GUI application ซึ่งเป็นการที่จะแยกสิ่งต่างๆ ออกจากกันให้เป็นสัดส่วน ไม่ให้หน้าๆ นึงมันอิรุงตุงนัง มีหลายๆ ส่วนปนกัน ซึ่งมันจะทำให้การเขียน code ง่ายขึ้น และง่ายต่อการปรับปรุง

ในโลกของ software เราได้สานต่อความคิดจากอดีตบ่อยมาก เมื่อก่อนนักพัฒนาเริ่มที่จะสร้าง web application พวกนี้จะเขียนอย่างอิรุงตัง ผสมๆ กัน ในส่วนของการแสดงผล เก็บข้อมูล เงื่อนไขต่างๆ และการควบคุมเหตุการณ์ต่างๆ ใน ไฟล์ๆ นึง เหมือนคืบคลานกลับไปสู่อดีตอีกครั้งนึง แต่พวกหัวใส เริ่มการทดลองกับสถาปัตยากรรมของ web application จนถึงทุกวันนี้ มันแสดงถึง 20 กว่าปีแล้วของ MVC ที่เกิดขึ้นมา ผลของการทดลองนี้ ได้สร้าง framework ต่างๆ ขึ้นมา ไม่ว่าจะเป็น WebObjects, Struts, หรือ JavaServer Face ซึ่งมีรากฐานมาจาก MVC ทั้งนั้น

Ruby on Rails(RoR) ก็เหมือนกัน เป็น MVC framework ด้วย มันจะควบคุมโครงสร้างสำหรับ models, views, และ controllers เป็นเหมือนการผ่าซุง ซึ่งฟืนแต่ละท่อนที่แยกออกมา ก็เสมือนหน้าที่ต่างๆ นั่นแหละ แล้วเอามาเรียงใหม่ให้มันดูดี หนึ่งในความสนุกของ Rails คือการที่ต้องมานั่งเรียงท่อนฟืนเหล่านี้แหละ แต่ตอนเรียงฟืนเนี่ย มันจะฉลาดและอัตโนมัติเอามากๆ จนเราสนุกไปกับมัน เราไม่ต้องเขียน configuration file อะไรเพิ่มเพื่อควบคุมสิ่งต่างๆ เลย นี่เป็นตัวอย่างของหลักการของ Rails คือ Convention over Configuration

ใน Rails application นั้น request ที่เข้ามานั้น จะเป็นสิ่งแรกที่ตัว application จะรู้จัก มันจะถูกแยกมาเป็นก้อนๆ แล้วค่อยถูกสั่งให้้ทำงาน(request มันจะเป็นก้อนๆ ต่อๆ กันอยู่ซึ่งเก็บที่ๆ นึง และ หน้าที่ๆ นึงอยู่ เดี๋ยวอธิบายต่อด้านล่าง) และที่พิเศษกว่านั้น ในส่วนนี้จะระบุ หน้าที่พิเศษ(action) ในที่ใดก็ได้ใน controller ตัว action นี้ อาจมองดูข้อมูลในก็ได้ อาจจะต่อกับ model ก็ได้ และอาจจะเรียก action อื่นๆ อีกก็ได้ จาก action ที่มันได้เตรียมข้อมูลต่างๆ ไว้แล้ว ก็เป็หน้าที่ของ view ที่จะแสดงผลให้กับผู้ใช้

รูปนี้แสดงถึงการความคุม request ที่เข้ามา ในตัวอย่างนี้ สมมติว่าหน้านี้ ได้ทำการแสดงหน้า catalog ไปแล้ว และผู้ใช้ได้คลิกปุ่มเพื่อที่จะเลือกสินค้าชิ้นนั้นๆ url ที่ได้จะเป็น http://mysite.url/store/add_to_cart/123 ซึ่ง 123 นั้น จะเป็น id ของสินค้าที่เราทำการเลือก¹

Rails จะรับ request ที่เข้ามาแล้วแตกมันออกทันที ส่วนแรกจะเป็น store ซึ่งเป็นชื่อของ controller ส่วนที่สองจะเป็น add_to_cart เป็นชื่อของ action และส่วนสุดท้ายเป็นการแตกออกเป็น parameter เรียกว่า id ซึ่งผลการแตก request ออกมา มันจะไปเรียก add_to_cart method ใน StoreController ให้ทำงาน (ใจเย็นๆ ครับ เดี๋ยวครั้งต่อๆ ไป จะมาอธิบายพวกชื่อต่างๆ ให้ฟัง)

add_to_cart method จะควบคุม request ที่ผู้ใช้ส่งเข้ามา ในกรณีนี้ มันจะหาตัวรถเข็น(shopping cart)ของผู้ใช้ แล้วจับสินค้า ที่ id=123 ใส่ในรถเข็น ซึ่งเจ้าตัวรถเข็นนี้จะเป็น model ตัวนึง แล้วรถเข็นนี้ก็จะมีสินค้าเข้ามาตัวนึง เราสามารถสั่งให้แสดงได้โดยใช้ view ในการแสดง

ทั้งหมดนี้แล ก็เป็น MVC web appcliation ถ้าเราสามารถเขียนการทำงานให้มันออกเป็นส่วนๆ ที่ชัดเจน มันก็ง่ายต่อการทำงาน และง่ายต่อการ debug หรือง่ายต่อการเพิ่มเติมมา ตัว RoR จะไปจัดการส่วน low-level ให้ อย่างเช่นการติดต่อนั่น ติดต่อนี่ เราไม่ต้องไปสนใจกับมันอีก หน้าที่เราเพียงแค่ตั้งใจทำหน้าที่หลักๆ ของมันเท่านั้นเอง

¹การใช้ get request ก็มีปัญหานะครับ อันตรายพอสมควร ถ้าใช้ผิดวิธี ไว้ว่างๆ ผมจะมาเล่าให้ฟัง ว่ามันจะอันตรายยังไง

ย้อนกลับไปที่ย่อหน้าแรกกันก่อน ของที่น่าสนใจของ Rails ยังไม่หมดนะครับ ไว้จะมาต่อกันคราวหน้า

แก้ไขล่าสุด วันที่ 4 กรกฏาคม 2550 เวลา 23.32 น.

NOTICE: post นี้ ข้อมูลเก่าครับ ว่ากันง่ายๆ เลย ผมขี้เกียจแก้ละ :)

บางคนที่ไม่เคยลองมาก่อน อ่านแล้วมันคงงงๆ น่าดู มาลองของจริงกันเลยดีกว่า แต่ต้องติดตั้ง PEAR::DB_DataObject เสร็จก่อนนะครับ ที่ผมจะแสดงให้ดู จะเป็นหน้าง่ายๆ หน้านึง มีข้อมูล มีปุ่ม คอยเพิ่ม ปรับปรุง และลบข้อมูลที่ถูกแสดง โดยจะเขียนตาม MVC design pattern(จะเอามาเล่าในคราวหลัง) จะมีโครงสร้างง่ายๆ ดังนี้

root
 -pearTest folder
   -pear_dbTest.php      -> view
   -manage.php
   -db.ini
   -Controller folder    -> Controller
     -UserMgr.php
     -Mgr.php
   -DataObjects folder   -> Model
     -Members.php         -> ได้จากการ generate
     -peartest.ini        -> ได้จากการ generate

อันดับแรก คงต้องไปสร้างฐานข้อมูลก่อน

Database name: peartest table: member

จากนั้น เราต้องการตัว class ที่จะทำหน้าที่เป็น Database เสมือน โดยตัว code ที่จะทำการ generate อยู่ที่ php\pear\DB\DataObject\createTables.php แต่ก่อนจะทำการ generate ต้องสร้าง configuration file ก่อน db.ini

• ผมใช้ XAMPP ครับ ไม่ได้ใช้ AppServ path บางตัวอาจจะไม่คุ้น ตัว folder ที่เป็นที่เก็บ source file จะเป็น peartest ถ้าเป็นใน AppServ ก็ควรจะอยู่ในหน้า root ของเว็บ

แล้วก็ไปเปิดหน้าต่าง dos ขึ้นมา แล้วเข้าไปใน php folder แล้วพิมพ์ว่า

php pear\DB\DataObject\createTables.php ..\htdocs\peartest\db.ini

ผลที่ได้

D:\apachefriends\xampp\php>php 

pear\DB\DataObject\createTables.php ..\htdocs\pea
rtest\db.ini
DB_DataObject_Generator   : 0       : CREATING FOR peartest

DB_DataObject_Generator   : 0       : calling generateDefinitions
DB_DataObject_Generator   : 0       : Generating Definitions file:
DB_DataObject_Generator   : 0       : Writing ini as D:\apachefriends\xampp\htdo
cs\peartest\DataObjects/peartest.ini

DB_DataObject_Generator   : 0       : calling generateClasses
DB_DataObject_Generator   : 0       : writing DataObjects_Member

DB_DataObject_Generator   : 0       : DONE

สิ่งที่เราจะได้หลังจากการ generate คือ Member.php กับ peartest.ini ลองเปิดดูได้

ถัดมา ก็มาดูที่หน้าที่ไว้แสดงหน้าตาง่ายๆ pear_dbTest.php

และ manage.php

และฝั่งที่ไว้ควบคุม ใน Controller folder จุดหมายหลัก อันนี้จะใช้ตัว DB_DataObject ซะที ลองดู code นะว่ามันง่ายขนาดไหน UserMgr.php

สังเกตได้เลยว่าไม่มี sql command สักตัว เย้ๆๆๆ ชอบๆ และตัวที่ไว้ Connect กับ Database Mgr.php

ปล. จริงๆ จะให้ดูแค่ code ตรงส่วนที่ใช้ PEAR::DB_DataObject เขียน แต่เดี๋ยวจะไม่เห็น ไม่ชัดเจน
ปอ. code เยอะจัด ขี้เกียจอธิบาย ไปแกะกันเองเน้อ ไม่เข้าใจตรงไหน โพสถามได้เลย

แก้ไขล่าสุด วันที่ 29 มิถุนายน 2550 เวลา 2.15 น.