"ผมถามอยู่หลายที ในเรื่องของการนำ CakePHP (และ Rails) ไปใช้ในงาน Enterprise ที่ค่อนข้างจะยึดติดกับ business ของลูกค้าเป็นหลัก แต่สุดท้ายก็ยังหาข้อสรุปกันไม่ได้ว่า จริงๆ แล้ว CakePHP มันเหมาะสมกับงาน Enterprise หรือยังจนกระทั่ง ผมได้มีโอกาสนำ CakePHP ไปใช้ในงานที่เทียบเท่าระดับ Enterprise นั่นคือ ต้องทำตาม business และ Operation ที่ระบุให้ได้ รวมไปถึงต้องทำงานกับระบบเดิม และ DB เดิม ได้ด้วยเช่นกัน ในงานนี้ ผมเลยต้องจำใจนำ CakePHP ไปใช้กับ SQL Server 2000 (ทั้งๆ ที่มันควรจะใช้กับ mySQL มากกว่า) ส่วนเนื้องานก็คือ ทำเป็นระบบ User Management ที่เอาไว้ให้ user จัดการเรื่อง password ของตัวเองใน application ต่างๆ ถ้าเขียนเป็น ER ก็จะได้ประมาณนี้
เห็นเนื้องานคร่าวๆ แล้ว หลายคนอาจจะบอกว่า เนื้องานเล็กๆ แบบนี้จะเรียก Enterprise ได้ยังไง?
ถูกต้องครับ มันจะไม่เป็น Enterprise เลย ถ้ามองตาม Interface เป็นหลัก เพราะยังไงแล้ว มันก็คือเว็บ ซึ่งปกติแล้วเว็บจะไม่ซับซ้อนเท่าไรนัก แต่ที่ผมยกให้งานตัวนี้ เทียบเคียงงานระดับ Enterprise ก็เพราะมีการออกแบบ Database ตามหลักทั่วๆ ไปที่มีใช้ในงานจริงในระบบใหญ่ๆ ไม่ใช่การออกแบบ database ทั่วๆ ไปที่เรามักจะทำกันในเว็บไซต์ ยกตัวอย่างเช่น database ตามเว็บต่างๆ ส่วนใหญ่มักจะมีคีย์อยู่ตัวเดียว นั่นก็คือ ID อะไรซักอย่าง แล้วก็ link ระหว่าง table กันด้วย ID นั้นๆ ทำให้ระบบ database ของเว็บไซต์โดยมากแล้ว จะไม่ซับซ้อนเท่าไรนัก เป็นต้น
ดังนั้น การจะระบุว่า CakePHP นั้นจะเหมาะกับงาน Enterprise หรือไม่ ผมจะมองดังนี้
- ความสามารถในการทำงานกับ DB ที่ออกแบบมาหลายๆ รูปแบบ
- ความสามารถในการ Customize ทุกๆ ส่วน
- Performance ในทุกๆ ด้าน
จากการใช้งาน CakePHP กับงานจริง ทำให้ผมรู้ว่า CakePHP มีจุดอ่อนใน โมเดล (Model) เป็นอย่างมาก เพราะว่าไม่สามารถรองรับกับการออกแบบ database จริงๆ ได้เลย โดยเฉพาะระบบ automation ในระดับ database ที่เป็นจุดเด่นของ CakePHP นั้น ใช้กับงานนี้ไม่ได้เลยซักนิด!!! ผมต้องสร้างโมเดลในทุกๆ table ไม่เว้นแม้แต่ table ที่เป็น relation (M:N) เพราะว่าตารางที่เป็น relation ของผมนั้น มันมี attributes อยู่ด้วย ซึ่ง CakePHP ไม่ได้ดึง Attribute ตรงนี้มาให้ (จบเห่ - -*)
จุดด้อยในโมเดลอีกอย่างหนึ่ง ที่ผมถือว่าร้ายแรงมาก นั่นก็คือ การสนับสนุน Primary key เพียงแค่ field เดียว ซึ่งในงานระดับ Enterprise แล้ว เป็นไปไม่ได้เลย ที่เราจะมี Primary key แค่ field เดียว ระบบยิ่งซับซ้อน จำนวน field ใน primary key ยิ่งมาก แต่ CakePHP กลับสนับสนุนแค่ field เดียว!!! จากจุดด้อยนี้ ทำให้ผมต้องเขียนโค้ดในส่วนของการดึงข้อมูลใหม่ทั้งหมด ทั้ง Insert update delete select เพื่อให้สามารถใช้กับตารางที่มี primary key มากกว่า 1 field ได้
จากจุดอ่อนทั้งสองจุดนี้ ทำให้ระยะเวลาในการ develope ของผมเพิ่มขึ้น พอๆ กับเขียนโค้ดเองเลย เพราะผมไม่ได้เตรียมตัวรับมือกับจุดอ่อนทั้งสองจุดนี้มาก่อนเลย และกว่าจะปลงได้ว่า CakePHP มีจุดอ่อนตรงนี้จริงๆ และตัดสินใจเขียนใหม่ทั้งหมด ก็กินเวลาเป็นวันอยู่เหมือนกัน
แต่ถึงแม้ว่าผมจะไม่ปลื้มกับ CakePHP ในส่วนของ model เลยซักนิด ก็ใช่ว่า CakePHP จะไม่มีดีเอาเสียเลย ในส่วนของ Controller กับ View นั้น ผมถือว่าใช้งานได้ค่อนข้างดี ช่วยให้โปรแกรมที่เขียน เป็นระบบยิ่งขึ้น ไล่โค้ดง่าย ยิ่งตอนที่จะต้องมีการ interrupt ด้วย message ซักตัวเช่น error หรือ warning message ก็สามารถทำได้อย่างง่ายดาย ไม่ต้องเสียเวลาจัดการข้อมูลเพื่อ resume session เหมือนกับการเขียนโค้ดเพียวๆ
สำหรับคุณสมบัติด้านการ customize ของ CakePHP นั้น ก็ได้รับอานิสงค์มาจาก OOP ที่เด่นเรื่องการ reuse ทำให้การ customize ใน CakePHP นั้น ถือว่าอยู่ในระดับที่ดีทีเดียว ช่วยให้ผมสามารถแก้จุดอ่อนของ Model ได้อย่างไม่ยากเย็นนัก (แต่จะดีกว่านี้ถ้าไม่ต้องมานั่งแก้ - ยังบ่นไม่เลิก)
ส่วนเรื่อง Perfermance ของ CakePHP ก็รู้สึกว่า มีหน่วงๆ บ้างเหมือนกัน ทั้งๆ ที่ใช้ localhost แล้วก็ตาม ซึ่งอาจจะเป็นผลพวงมาจากระบบ automation ทั้งหลายแหล่นั่นแหละ ผมมองว่า ถ้าลด automation บางอย่างไป จะช่วยเรื่อง performance ให้ดีขึ้นได้อีกเยอะ (เช่น naming, auto join เป็นต้น) แต่ในระบบที่ผมทำนั้น เป็นระบบ intranet มีผู้ใช้ต่อช่วงเวลา ไม่เยอะนัก ฉะนั้นหน่วงนิดๆ แค่นี้ คงจะฟันธงถึงประสิทธิภาพของ CakePHP ไม่ได้ซะทีเดียว
สรุปแล้ว โดยรวมถือว่า CakePHP ช่วยในเรื่องโครงสร้างของโปรแกรมได้เป็นอย่างดี แต่กับการทำงานกับ Database แล้ว ผมถือว่ายังทำได้ไม่ดีพอสำหรับการนำไปใช้กับงานระดับ Enterprise ส่วนในเรื่อง performance ผมขอผ่านก็แล้วกัน เพราะไม่ได้ทดสอบแบบจริงๆ จังๆ
ป.ล. ผมไม่แน่ใจว่า Model จะทำงานได้สมบูรณ์กับ MySQL หรือไม่ เพราะงานนี้ผมเล่นกับ SQL Server"
ที่มา: http://weblog.punneng.com
ไม่มีความคิดเห็น:
แสดงความคิดเห็น