หลักการเขียนโปรแกรม ตอนที่ 2

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

ในการเขียนโปรแกรมก็เหมือนกัน เราต้องทำการจัดการ Source Code ของเราให้เหมือนกับการจัดการหนังสือในห้องสมุด เราต้องทำการแบ่งแยก Source Code ของเราออกเป็นหมวดหมู่หรือเป็นเรื่องๆ

ซึ่งหลักการนี้เรียกว่า Separation of Concern (SoC) หลักการนี้จะนำไปสู่หลักการเขียนโปรแกรมต่างๆมากมาย ไม่ว่าจะเป็น Object Oriented Programming (OOP) หรือ จะเป็น Architecture Pattern ชื่อดังอย่าง MVC ก็ล้วนแล้วแต่เกิดขึ้นมาเพื่อตอบสนองหลักการนี้ทั้งสิ้น

ในการนำหลักการนี้ไปทำการ Implement นั้นก็ต้องใช้แนวคิดหรือ Design Pattern ต่างๆ

  • Object Oriented (OOP)
  • Aspect Oriented Programming (AOP)
  • MVC
  • MVP
  • MVVM
  • Service Oriented Architecture (SOA)
  • และอื่นๆ

ขึ้นอยู่กับว่าเราต้องการแยกส่วนประกอบต่างๆออกมาละเอียดขนาดไหน ซึ่งแต่ละตัวเราจะทำการพูดถึงในบทความตอนต่อๆไป

แต่ที่นำหลักการนี้มาไว้ในบทความตอนแรกๆ เนื่องจากเป็นหลักการที่สำคัญ ก่อนที่เราจะเรียนรู้ OOP เราต้องเรียนรู้หลักการนี้ก่อน ไม่งั้นเราจะใช้ Syntax แบบ OOP แต่เราไม่ได้ใช้วิธีการคิดแบบ OOP เลย เพราะ OOP เป็นการ Speration Code ออกจากกันโดยแยกเรื่องที่ไม่เกี่ยวข้องกันออกจากกัน (เนื่องจาก คำว่า Class ใน OOP ย่อมาจาก คำว่า Classify หรือ Classification)

ทำความรู้จักกับ Eloquent

หลายคนที่ได้ใช้ Laravel ส่วนหนึ่งคงจะติดใจการใช้งานตัว ORM อย่าง Eloquent ซึ่งใช้ Active Record Pattern เหมือนกับใน Ruby on Rail ซึ่งจะทำให้เราสามารถทำงานกับฐานข้อมูลได้อย่างง่ายดายและเป็น OOP แบบ 100% ซึ่งความสามารถของ Eloquent นั้นทำได้หลายอย่าง ทั้งเรื่องของ Query Builder ซึ่งจะเหมือนกับ Active Record ใน CI เราสามารถทำงานกับฐานข้อมูลโดยที่ไม่ต้องทำการ Map Object เลย Feature นี้จะเหมาะกับคนที่ยังติดอยู่กับการเขียน Query ด้วย SQL

นอกจากนี้ยังมีส่วนของ ORM ซึ่งต้องทำการ Mapping ก่อนการใช้งาน แต่การ Mapping แบบ Acrive Record นั้นง่ายมากๆ

ส่วน Featuure พื้นฐานอื่นๆ เช่นการสร้าง Connection ไปยัง Database หลายๆตัว หรือการ return ผลลัพธ์กลับมาเป็น Array หรือ JSON ก็มีให้ใช้งานอย่างครบถ้วน

ส่วน Feature ที่เด็ดมากของ Eloquent คือมีตัว Migration ทำให้เราสร้าง Schema ของ Database เก็บไว้ใน Code เลย (เราสามารถ Generate Table ใหม่กี่ครั้งก็ได้ ) ต่อไปนี้เราไม่ต้องแยกทำ Version Control ของ Database Schema อีกต่อไป

การทำงานกับการ Insert, Update และ Delete แบบทีละหลายๆ Record ก็ทำได้ง่าย

เรื่องของความรวดเร็วก็ต้องบอกว่าทำงานได้เร็ว โดยที่ไม่รู้สึกว่ามี ORM

ส่วนเรื่องของ Database ที่ Support นั้น มีหลายตัว ประกอบไปด้วย MySQL, Postgres, SQLite, and SQL Server เสียอย่างเดียวยังไม่ Support Database ยักษ์ใหญ่อย่าง Oracle

ข้อเสียอีกอย่างที่สำคัญมากคือ การ Mapping แบบ Single Table Inheritance และ Create Table Inheritance ยังทำไม่ได้ แต่ก็มีคนสร้าง plugin ต่างๆ  เพื่อพยายามปิดช่องโหว่ตรงนี้

แต่โดยรวมแล้วถือว่าเป็น ORM ที่น่าใช้งานเป็นอย่างยิ่ง

เปิดอบรมหลักสูตรการใช้งาน CodeIgniter วันที่ (14 – 18 มกราคม 2556)

หลักสูตรนี้จะอธิบายถึงหลักการของ MVC โดยใช้ Codeigniter ซึ่งเป็น framework ที่มีขนาดเล็กและใช้งานได้อย่างรวดเร็ว ผู้เรียนจะต้องมีพื้นฐานการเขียนโปรแกรมด้วย PHP มาเป็นอย่างดี โดยเราจะเน้นที่วิธีการออกแบบและใช้ประโยชน์จาก MVC Framework ให้ได้มากที่สุด

  • สถานที่เรียนอยู่ชั้น 10 อาคาร Software Park ตรงข้าม Central แจ้งวัฒนะ
  • เวลาเรียน 5 วัน
  • ราคา 10,000 บาท ถ้านำ Notebook มาเองลดเหลือ 8500 บาท

หรือสามารถเข้าไปติดต่อสอบถามรายละเอียดเพิ่มเติมได้ที่ www.facebook.com/irobust

นอกจากนี้ยังมีหลักสูตรอื่นๆอีกมากมายเข้าไปดูได้ที่ www.irobust.co.th

Angular JavaScript น้องใหม่

วันนี้มานำเสนอ JavaScript Framework ตัวใหม่ชื่อว่า AngularJS เป็น JavaScript สำหรับทำ Dynamic UI ได้อย่างง่ายดายไม่ต้องเขียน Selector ให้เหนื่อย กำหนดว่าส่วนไหนเป็น Model View หรือ Controller ที่เหลือตัว AngularJS จะจัดการให้

ลองเข้าไปทดลองแก้ไข code ได้ที่
http://jsfiddle.net/irobust/wK3Ty/

เข้าไปดูข้อมูลและตัวอย่างเพิ่มเติมได้ที่
http://angularjs.org/

Service Layer กับ MVC

หลังจากที่อธิบายถึงแนวคิดในการใช้งาน MVC Framework มาแล้วต่อไปเราจะเจาะลึกลงไปในส่วนของ Model ที่มีการเพิ่มส่วนของ Service Layer ขึ้นมาเพื่อที่จะทำให้เราสามารถ maintain ในส่วนของ model ได้ง่ายขึ้น การสร้าง Service Layer เราจะทำการประยุกต์แนวคิดของ Service Oriented Architecture (SOA)  มาใช้งานร่วมกับ MVC

Service Oriented Architecture

ก่อนอื่นต้องอธิบายความหมายของ Service Oriented Architecture (SOA) ก่อน SOA เป็นแนวความคิดที่ถูกนำไปประยุกต์ใช้งานเกี่ยวกับ Web service เป็นส่วนมาก แต่ความจริงแล้วแนวความคิดนี้สามารถนำมาประยุกต์ใช้งานใน Model ได้ด้วย โดย SOA เป็นแนวคิดที่มองการทำงานส่วนต่างๆเป็น service หรือ บริการเพื่อให้นำกลับมาใช้ใหม่ได้ง่าย และยังลดความซ้ำซ้อนของข้อมูลในองค์กรได้ด้วย เพราะถ้าต้องการข้อมูลอะไรก็สามารถเรียก service ตัวนั้นขึ้นมาทำงานได้เลย จากรูปด้านซ้ายจะเป็นแนวคิดแบบเดิม Silo เรียกง่ายๆว่า Applicationของใครของมัน Application แต่ละตัวจะแยกกันทำงานและแน่นอนข้อมูลบางส่วนก็จะซ้ำซ้อนกัน จึงมีแนวคิดในการมองทุอย่างเป็น service และ integrate หรือ บูรณาการเข้าด้วยกัน ด้วยหลักการทำงานเป็น service ทำให้ถูกนำไปใช้คู่กับ Web service เป็นหลักในหลักการของ SOA เราจะทำการกำหนด flow ด้วย Enterprise Service Bus (ESB) ทำหน้าที่เชื่อมโยง service ต่างๆเข้าหากัน การแยก work flow ออกมาทำให้เราสามารถปรับเปลี่ยน work flow ได้ตามต้องการโดยไม่กระทบกับ service เลย ถ้าอ่านดูแล้วคงจะคุ้นกับแนวคิดแบบนี้เพราะมันคือ Controller ใน MVC นั่นเอง
Service Layer

จากรูปเราจะเห็นว่าการสร้าง service จะอยู่ครอบ domain model หรือการทำงานข้างในของ model โดยจุดประสงค์ของการสร้าง service ใน MVC ก็เพื่อที่จะครอบการทำงานข้างใน model เพื่อลดความซ้ำซ้อนลง และผลที่ได้ตามมาอีกอย่างคือจะลดความขึ้นต่อกัน(couple)ลง ทำให้เราสามารถถอดเอาส่วนต่างของระบบไปใช้งานใหม่ได้ง่ายขึ้น และตามหลักของ Software Engineering เราต้องพยายามที่จะทำระบบให้ high cohesion และ low couple ที่กล่าวมาทั้งหมดนี้ก็เป็นประโยชน์ที่จะได้มากมายจากการสร้าง Service Layer ใน Model

References:

http://martinfowler.com/eaaCatalog/serviceLayer.html

http://msmisthammasat.blogspot.com/2011/01/soa-service-oriented-architecture.html

แนวคิดเกี่ยวกับ MVC

ในยุคนี้คงไม่มีทางที่เราจะหนีคำนี้ได้พ้นเพราะในการพัฒนาระบบในปัจจุบันขนาดของโครงการจะใหญ่ขึ้นเรื่อยๆ เนื่องจากความต้องการมีสูงขึ้นเรื่อยๆ ดังนั้นการจะพัฒนา software ด้วยตัวคนเดียวเป็นเรื่องยาก จึงมีการประยุกต์ใช้งาน Enterpirse Architecture Pattern อย่าง MVC กันมากขึ้นในทุกๆ platform ด้วยเหตุนี้การจะใช้งาน MVC Framework ตัวใดก็แล้วแต่ไม่ว่าจะเป็น PHP , .NET หรือ Java ล้วนแล้วแต่ต้องอาศัยแนวความคิดที่ถูกต้องจึงจะเป็นประโยชน์อย่างแท้จริงไม่เช่นนั้นนอกจากจะไม่มีประโยชน์ใดๆ ในการใช้ Framework แล้ว ยังเป็นดภาระในการแก้ไขซึ่งจะทำให้แก้ไขได้ยากกว่าปกติ ดังนั้นจึงเริ่มจากการแนะนำแนวคิดในการแบ่งแยกส่วนของ code ออกเป็น 3 ส่วนด้วยกันคือ
MVC Archtecture Pattern

  • Model (M) เป็นส่วนของ Business Logic และ ส่วนของ Entity ซึ่งส่วนนี้จะแตกต่างจากแนวคิดแบบ 3-tier ซึ่งจะแยกส่วนล่างสุดเป็น Data Access Layer (DAL) ซึ่งจะทำหน้าที่ติดต่อกับ Database เท่านั้น แต่ Model จะไม่ได้เป็นเพียงแครการติดต่อกับ Database เท่านั้น แต่ยังรวมเรื่องของ Business Logic ต่างด้วย เช่น การคำนวน VAT 7% หรือการคำนวนค่าต่างให้อยู่ในชั้นนี้ และถ้าจะให้ดีชั้นนี้ควรจะทำการสร้าง Service Layer ขึ้นมา ตรงนี้จะลงรายละเอียดในบทความถัดไป
  • View (V) เป็นส่วนของการแสดงผลอันนี้ตรงตัวไม่ต้องคิดมาก เป็นส่วนของ HTML ,CSS และ JavaScript ในการทำ Web Application แต่ถ้าเป็น Windows Application ก็จะเป็นพวก forms ต่างๆ ในการใช้งาน PHP Framework บางตัวจะพ่วงเอา Template Engine มาให้ใช้งานด้วย เช่น Symfony จะมี Twig เป็น Template Engine ซึ่งข้อดีของการใช้งาน Template Engine ก็คือจะทำการแยกส่วนของการแสดงผลกับ logic ได้ชัดเจนมากขึ้นคนที่ทำ HTML CSS และ JavaScript ไม่จำเป็นต้องเขียน PHP ได้
  • Controller (C) ส่วนนี้เป็นส่วนสมองของระบบจะทำหน้าที่คอยควบคุมว่าจะดึงข้อมูลจากไหน (Model ตัวไหน) แล้วก็ไปแสดงผลยังไง (View ตัวไหน) ส่วนนี้จะเป็นส่วนที่่ผิดกันเป็นประจำสำหรับผู้ที่เริ่มใช้งาน MVC Framework เพราะเป็นส่วนที่เราไม่เคยแยกส่วนนี้มาก่อน ส่วนของ Controller จะเป็น work flow หรือขั้นตอนการทำงานต่างๆ (มีเฉพาะ flow ของการทำงานเท่านั้น) จะไม่มี logic ใดๆในนี้ไม่มีการเขียน HTML ไม่มีการคำนวนค่าต่างๆ หน่าที่ของ Controller มีเพียงแค่รับค่ามาทำการ Validate แล้วส่งเข้าไปที่ Model เท่านั้น

ประโยชน์ของการใช้ MVC ก็คือการเพิ่ม maintainability หรือทำให้ระบบแก้ไขได้ง่ายขึ้นเพราะมันแยกส่วนออกจากกันอย่างชัดเจน อีกข้อนึงที่สำคัญไม่แพ้กันก็คือเราจะสามารถแยกคนทำงานตามสิ่งที่เค้าถนัด เช่น คนทำ View ไม่ต้องรู้ว่า database มีโครงสร้างยังไง คนที่ทำผั่ง model ก็ไม่ต้องมากังวลเรื่องของการแสดงผล แต่ขอให้ตกลงเรื่องของ data ที่ส่งหากันให้ดีก็พอ

สุดท้ายอาจไม่จำเป็นจะต้อง strict อยู่ในรูปแบบนี้ 100% เพราะนี่เป็นเพียงทฤษฏี แต่ยังไงก็ตามถ้าจะเขียนผิดไปจากนี้ (anti pattern) ก็สามารถทำได้แต่ต้องแน่ใจว่าการทำแบบนั้นมีเหตุผลมากพอที่จะทำ และไม่กระทบกับการแก้ไขในอนาคต