Repository Pattern คือหนึ่งใน Design Pattern ที่ได้รับความนิยมมากที่สุดในการพัฒนาซอฟต์แวร์สมัยใหม่ โดยเฉพาะในการเขียนโปรแกรมเชิงวัตถุ หน้าที่หลักของมันคือการสร้าง “เลเยอร์กลาง” ระหว่าง Business Logic และ Data Source เพื่อให้โค้ดสะอาดและดูแลรักษาง่ายขึ้น
ทำไมเราต้องใช้ Repository Pattern ?
ลองนึกภาพว่าถ้าคุณเขียน Code ติดต่อกับ Database โดยตรงไว้ใน Controller ทุกครั้งที่คุณต้องการเปลี่ยนจาก SQL Server เป็น MongoDB หรือแม้แต่การเปลี่ยนโครงสร้าง Table คุณจะต้องไล่แก้ Code ในทุก ๆ หน้าที่เรียกใช้ ซึ่งเป็นฝันร้ายของนักพัฒนา
โครงสร้างและหลักการทำงาน
Repository Pattern ทำงานเหมือนเป็น “คลังสินค้า” ของข้อมูล
- Domain / Service Layer: จะไม่สนใจว่าข้อมูลถูกเก็บไว้ที่ไหน มันแค่สั่งว่า “ขอข้อมูล User ID 1 หน่อย”
- Repository Interface: กำหนดมาตรฐานว่า Repository นี้ทำอะไรได้บ้าง
- Data Access Logic: ส่วนที่ Implement คำสั่งจริง เช่น การเขียนคำสั่ง SQL หรือการเรียกใช้ ORM
ข้อดีของ Repository Pattern
- Decoupling : Business Logic ไม่ยึดติดกับเทคโนโลยีของฐานข้อมูล
- Maintainability : เมื่อมีการเปลี่ยน Logic การดึงข้อมูล คุณแก้เพียงจุดเดียวคือใน Repository Class
- Testability : ง่ายต่อการทำ Unit Testing เพราะเราสามารถสร้าง “Mock Repository” มาแทนที่การต่อ Database จริงได้
- Don’t Repeat Yourself : ลดการเขียน Query ซ้ำซ้อนในหลาย ๆ ที่ของโปรเจกต์
ตัวอย่างการเขียน
เพื่อให้เห็นภาพชัดเจน
Interface
interface IUserRepository { User GetUser (int id) ; void Save (User user) ;
}
Implementation
class UserRepository : IUserRepository { public User GetUser (int id) { // เขียนคำสั่งดึงข้อมูลจาก Database จริงที่นี่ return db.Users.Find (id) ; }
}
Usage
// ใน Service หรือ Controller
var user = userRepository.GetUser (1) ;
ข้อควรระวัง
แม้จะมีข้อดีมากมาย แต่ Repository Pattern ก็อาจทำให้โปรเจกต์ขนาดเล็กดู “ซับซ้อนเกินจำเป็น” ได้ หากระบบของคุณมีการทำแค่ CRUD แบบพื้นฐาน การเรียกใช้ ORM โดยตรงอาจจะรวดเร็วกว่า
แต่สำหรับโปรเจกต์ระดับ Enterprise หรือระบบที่ต้องมีการทำ Unit Test อย่างเข้มข้น Repository Pattern คือเครื่องมือที่ขาดไม่ได้เลยครับ
อ่านเพิ่มเติม