สวัสดีครับ เพื่อน C# Community ทุกคน เข้าเรื่องเลยนะครับ

ในห้องนี้คงไม่เคยมีใครไม่เคยใช้ หรือ ไม่รู้จัก Visual Studio 2005 นะครับ
เพราะบทความนี้ได้ตั้งสมมติฐานว่าผู้อ่านควรจะเคยใช้งาน IDE ตัวนี้มาบ้าง

จากที่ผมลอง survey หนังสือเกี่ยวกับการเขียนโปรแกรมในสไตล์ Visual ของฝั่ง Microsoft ในบ้านเรา
(ซึ่งก็แทบจะครอบครองพื้นที่บนชั้นหนังสือบ้านเราเกิน 80% หรือมากกว่านั้น)
โดยเฉพาะในหัวข้อของ Database Application. นั้น ผู้ประพันธ์ทุกคนจะเขียนโดยใช้เทคนิคเดียวกันหมดนั่นคือ ใช้การเขียนโปรแกรมโดยฝัง Code ของ ADO.NET เข้าไปใน Form เลย ทั้งที่แบบใช้ Wizard และ เขียน Code ขึ้นมาเองทั้งหมด

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

ยกตัวอย่างนะครับ

สมมติผมมี Form อยู่ 4 Form ซึ่งเป็นForm ที่จะมีการตรวจเช็คว่า สินค้านี้มีการเบิกไปหรือยัง โดย SQL Statement อาจจะเป็นดังนี้

COUNT(*)
FROM PRODUCT
WHERE IsWITHDRAW = 0

จากนั้นภายใน Form ที่เราจะสร้างก็จะต้องทำการ เริ่ม สร้าง Dataset, DataAdapter, DataTable, SQLCommand, SQLConnection จากนั้นคุณก็จะต้องนำ SQL Statement ดังกล่าวมา Instantiation ให้กับ DataAdapter แล้วก็ทำการ Fill ผลลัพธ์ลงไปใน DataSet และก็ใช้ DataTable มาดึงข้อมูลจาก DataSet เพื่อนำมาแสดงผลต่อไป

สำหรับคนที่เขียน ADO.NET จนคล่องเหมือนกับอยู่ในสายเลือดก็คงไม่มีปัญหาอะไร ในตอนเริ่ม Implement ระบบ แต่คราวนี้ผมลองสมมติสถานการณ์ว่า มีความจำเป็นต้องยกเลิกเจ้า Field IsWITHDRAW ซึ่งมี Data Type เป็น BIT (ซึ่งก็คือ Bool data type ของ C# นั่นเอง) แล้วเปลี่ยนมาใช้ Field ใหม่ที่ชื่อว่า STATUS ซึ่งใช้บอกมากกว่า เบิก/คงเหลือ คราวนี้ครับ เราคงต้องเริ่มกลับไปหา Form ทั้ง 4 Form ที่เราสร้างเอาไว้ แล้วเข้าไปแ้ก้ SQL Statement ทั้งหมด(ซึ่งก็เป็นค่า string ทั้งหมด ทำให้เวลาเราเข้าไปแก้ข้อมูลก็ไม่มี Intellisense เข้ามาช่วย เสี่ยงต่อการพิมพ์ผิดเข้าไปอีก) แล้วก็ลองรันดู คราวนี้ใช้่งานได้ก็โล่งใจไป ปล่อยไปซัก 3 วัน อยู่ User ก็โทรมาหาคุณว่า โปรแกรมมันฟ้อง Error อะไรก็ไม่รู้ขึ้นมา (Error ที่ส่งผ่านมาจาก SQLServer มายัง Form นั้นดูน่ากลัวมาก แม่แต่กับ Developer ก็เถอะครับ) พอเราเข้าไป Debug ก็ปรากฎว่าภายในฟอร์มเดียวกันนั้นก็มีการอ้างอิง เจ้า Field นี้อยู่ในส่วนอื่นๆ ของ ฟอร์มด้วย ก็ต้องมานั่งไล่แก้กันไป (อาจจะใช้วิธีการ Find and Replace ก็ได้ครับ)

OK ครับ ที่ผมพูดมาตั้งยืดยาวนี้ก็เพื่อจะบอกว่า การที่เราฝัง Code ADO.NET ลงไปใน Form นั้นถือเป็น Bad Practice นะครับ และมันก็ขัดกับหลักการของ Good Object-Oriented Design ในเรื่องของการทำ Coherent, Loosely Couple (การแบ่งหน้าที่กันทำ และการเป็นอิสระจากกันให้มากที่สุด) หลายคนอาจจะบอกว่าปัญหาข้างต้นอาจจะแก้ไขได้ โดยการไปเขียน Stored Procedure แล้วใช้ ADO.NET มาเรียกใช้ก็ได้ ผมก็ถือว่านี้เป็นทางแก้อีกทางหนึ่ง แต่สมมติว่าได้มีการแก้ stored procedure นั่นอีกล่ะ!!!!!!!!!!!!!!!
ฟังดูเหมือนผมเริ่มงี่เง่า แต่จริงๅ แล้วประเด็นก็คือว่า การที่เราฝัง Low Level Code อย่าง ADO.NET ลงไปใน User Interface นั้นจะทำให้ Form ของเรา ผูกติด (Highly Couple) กับ Database ทำให้เมื่อมีการแก้ Schema ในฝั่ง Database เราก็จะต้องมาไล่แก้ Logic ใน ฟอร์มของเราด้วย

ใน Visual Studio 2005 ได้มีความพยายามที่จะทำให้การพัฒนาระบบ ไม่ว่าจะเล็กหรือใหญ่ อยู่ในลักษณะของ Best Practice ให้มากขึ้น โดยมีเรื่องของ Typed DataSet เข้ามา และ้ใช้งานง่ายมาก ตาม style Microsoft โดย Low Level ทั้งหมด ไม่ว่าจะเป็น การ Connect กับ Database การ Fill Dataset การตั้ง Relation ในระดับของ Application ไม่ใช่ Database การแสดงผลของ Table แบบ Master-Detail และอีกหลายๆ อย่างที่พวกเราเคยทำ และไม่เคย เจ้า Typed Data Set นี้มีให้หมด

เจ้า Typed Data Set นี้ก็เป็น object หนึ่ง ดังนั้น การใช้งานของ Database จะเปลี่ยนไปอยู่ในรูปแบบของ Object-Oriented เต็มตัว เช่น ชื่อ Field ต่างๆ แทนที่เราจะต้องนั่งจำว่าในแต่ละ Table มีชื่ออะไรบ้าง แล้วมาเขียนภายใต้เครื่องหมาย " " ซึ่งก็ไม่รู้ว่าจะพิมพ์หรือเปล่าโดยเฉพาะเจ้าคำที่คนไทยเราเกลียดเหลือเกินกับไอประเภท Contains, Withdrawed และอะไรอีกหลายอย่างที่จะต้องมีการแสดง tense หรือ จำนวนของมัน ก็พิมพ์ผิดไปตามระเบียบ แต่ถ้าเป็น เจ้า Typed Data Set นี้ ทุกๆ Field จะถูกมองเป็น Properties ของ Typed Dataset object ดังนั้นเราจึงใช้ Intellisense ได้ การดึงข้อมูลผ่าน SQL Statement หรือ Stored Procedure ก็ทำงานผ่านเพียง Method ของ เจ้า object ดังกล่าว Developer ในฝั่ง User Interface ก็จำเป็นที่จะรู้เีพียงว่า จะต้องใช้ Method อะไร และต้องใ่ส่ Parameter อะไรลงไปบ้างแค่นี้เอง

ประโยชน์อีกอย่างหนึ่งก็คือ ถ้าเราพัฒนาระบบโดยใช้วิธีนี้ Code ทางด้าน UI จะไม่มีอะไรที่เกี่ยวข้องกับ Database และเรายังสามารถ แตก Typed Data set นี้ออกเป็น Project ต่างหาก สมมติว่าต่อไปเราจะพัฒนา Web Interface ก็จะสามารถใช้งาน Typed Data set ร่วมกันกับ Desktop Interface ได้ด้วย

ผมเมื่อยมือแล้วครับ วันหลังเรามาเจาะลึกในด้าน Technic กัน ไปแล้วครับ

ไม่ได้ต้องการเพื่ออวดรู้ แต่ต้องการจุดประเด็นเพื่อถกเถียง อยากให้บรรดา "เทพ" ที่ซ่อนตัวอยู่ได้ปรากฏตัวออกมา