ทำไมต้องใช้ Lazy Loading ใน Data Model ด้วยนะ ?

หลังจากที่พูดคุยเรื่อง ORM (Object Relation Mapping) ก็พบว่ามักจะพูดคุยเรื่องปัญหาของ dependency graph ที่เกิดขึ้น ซึ่งส่วนใหญ่มักจะประสบภัยกับเรื่องนี้อย่างมาก เมื่อระบบเริ่มมี model หรือ entity และความสัมพันธ์มากขึ้น สุดท้ายส่งผลให้ระบบพังสิครับ หรือไม่เช่นนั้นก็ memory หมด (OutOfMemory) ทำไมถึงเป็นเช่นนั้นนะ ? ปล. Lazy loading ยังเป็น feature ในเรื่อง ๆ อื่น ๆ อีกนะ

วิธีการที่ใช้แก้ไขปัญหาก็มีหลายแนวทาง เช่น

• ไม่ต้องมี relation ในระดับ model ทำการ mapping model กับ table/entity กันแบบ 1 ต่อ 1 เลย
• ถ้ายังไม่ใช้ก็ไม่ต้องไป load มาสิ ค่อยไป load เมื่อต้องการใช้งาน (Lazy loading)
• เพิ่ม memory สิ เรารวย
• เลิกใช้เลย

มาว่ากันเรื่องของ Lazy loading กันดีกว่า

ไปเจอบทความเรื่องที่น่าสนใจคือ Lazy loading is a code smell ทำการอธิบายไว้อย่างน่าสนใจ ว่า Lazy loading มันคือ code smell รูปแบบหนึ่ง model/entity class นั้น ๆ ต้องมีปัญหาแน่นอน เพราะว่ามีทั้งสิ่งที่ต้อง load เพื่อใช้งาน และมีสิ่งที่อาจจะไม่ต้องใช้งาน รวมกันอยู่ใน model class เดียวกัน

นั่นคือ เรากำลังออกแบบผิดหรือไม่ model เราผิดหรือไม่ ? กรอบหรือขอบเขตการทำงานผิดหรือไม่ ? model แต่ละตัวควรมีรูปแบบหรือโครงสร้างตามการใช้งานหรือไม่ ?

มาดูตัวอย่างกัน [gist id="a5d88bc87fcc45f72899a9a1600e7510" file="User.java"] คำอธิบาย ใน class User นั้นมีสิ่งที่ต้อง load อย่างเดียวคือ Name ส่วน Role และ Subscription เป็น optional นั่นคือมีหรือไม่มีข้อมูลก็ได้ แล้วจะมีไปทำไม ? คำถามที่เกิดขึ้นมาคือ ทำไมเราถึงออกแบบ model class แบบนี้ ? ทั้ง ๆ ที่ User นั้นถูกใช้งานที่แตกต่างกัน สิ่งที่เราต้องหาคำตอบให้ได้คือ

• User จะมี Role เมื่อใด ?
• User จะมี Subscription เมื่อใด ?
• User จะมีเฉพาะ Name เมื่อใด ?

ถ้าตอบได้เราจึงทำการออกแบบหรือสร้าง model class ตามการใช้งาน จากบทความอธิบายไว้ว่า

• User จะมี Role เมื่อผ่านการ authentication และ authorization มาแล้ว
• User จะมี Subscription ได้ เมื่อมีข้อมูล report
• User จะมีเฉพาะ Name คือ User ที่ใช้ทั่วไปในระบบ

เมื่อได้คำตอบแล้วจึงทำการสร้าง class ต่าง ๆ ได้ดังนี้ [gist id="a5d88bc87fcc45f72899a9a1600e7510" file="FinalUser.java"] ข้อดีของแนวคิดนี้คือ แต่ละ class อธิบายตัวมันเองชัดเจน (Descriptive) และมีเป้าหมายที่เฉพาะเจาะจง ทำให้การใช้งานง่ายและสะดวกขึ้น แต่ผลเสียคือมี class จำนวนมากขึ้น ซึ่งจะมองเป็นข้อดีหรือข้อเสียก็ได้ ขึ้นอยู่กับมุมมองและประสบการณ์ที่ผ่านมา รวมทั้งจำเป็นต้องเข้าใจการทำงานและใช้งานด้วยนะ ซึ่งจำเป็นมาก ๆ เมื่อระบบเริ่มมีขนาดใหญ่ขึ้น

คำถามที่น่าสนใจคือ เราทำการออกแบบ model กันอย่างไร ?