service-repository pattern

Có nhiều bài viết về service-repository pattern trên mạng, tuy nhiên các bài viết này thường triển khai code luôn, đâm ra nhiều người vẫn cảm thấy khó hiểu. Code lại cũng toàn CRUD thôi nên lại càng không hiểu được lợi ích của pattern này mang lại, đến lúc tự mình triển khai thì không biết đoạn code nào nên viết ở đâu. Thế nên mới có bài viết này.

Hãy tưởng tượng ứng dụng của chúng ta là một công ty, lúc này service-repository pattern được biểu diễn như sau:

  • Controller là giám đốc
  • Service là trưởng phòng
  • Repository là em văn thư

Controller

Ban đầu, công ty nhỏ, giám đốc muốn thưởng nhân viên, giám đốc trực tiếp dùng excel để lấy danh sách nhân viên luôn. Lúc này nhiệm vụ của giám đốc (Controller) quá nặng nề, vừa phải cân nhắc thưởng nhân viên nào (business logic) vừa phải xuất excel (data access).

Controller => Database

Repository

Sau đó công ty làm ăn phát đạt, điều này giống như khi ứng dụng của chúng ta lớn lên. Giám đốc thuê 1 em văn thư (Repository) làm nhiệm vụ xuất excel cho ổng. Ổng bảo em văn thư in cho anh danh sách nhân viên để anh thưởng.

Giám đốc chỉ làm nhiệm vụ thuộc về business (cân nhắc thưởng nhân viên nào) mà thôi. Ổng KHÔNG cần biết em văn thư đặt tên cột là gì, lưu trữ danh sách nhân viên ở đâu, excel, google sheets, database, file text, call api… Chỉ cần biết là cứ bảo xuất cho anh danh sách nhân viên là em văn thư xuất được (tất nhiên theo format ổng đưa ra, chúng ta sẽ nói về cái này ở bài viết khác)

Repository là lớp trung gian giữa business logic và data access (Em văn thư là trung gian giữa giám đốc và file excel)

Controller => Repository => Database

Service

Thời gian trôi qua, công ty lớn lên nữa. Giám đốc bận trăm công nghìn việc, mặc dù đã có em văn thư làm các công việc liên quan đến excel nhưng công việc của giám đốc (business logic) vẫn quá nhiều.

Ổng chia công ty thành các phòng ban, thuê vài anh trường phòng (Service), mỗi người làm một phần việc chuyên biệt cho ổng. Trưởng phòng hành chính nhân sự, trưởng phòng marketing, trưởng phòng kinh doanh…

Giám đốc bảo anh trưởng phòng hành chính nhân sự: Em thưởng nhân viên cho anh. Anh trưởng phòng nhân sự (Service) bảo em văn thư xuất danh sách nhân viên để anh thưởng.

Giám đốc (Controller) KHÔNG cần biết anh trưởng phòng nhân sự thưởng thế nào. Anh Trưởng phòng (Service) cũng KHÔNG cần biết em văn thư lưu trữ danh sách nhân viên ở đâu.

Lúc này:

Controller => Service => Repository => database

  • Anh trưởng phòng hành chính nhân sự chỉ làm các việc liên quan đến hành chính nhân sự thôi. Như vậy một cty có nhiều trưởng phòng (service)
  • Có những công việc giám đốc cần gọi nhiều trưởng phòng lên mới làm được.
  • Em văn thư lưu trữ danh sách nhân viên ở đâu, thế nào thì tuỳ cô ấy. Cô ấy đặt tên cột trong excel là gì thì cũng không ảnh hưởng gì đến anh trưởng phòng. Như vậy phải code sao cho khi đổi tên một cột trong db thì không phải sửa code logic nghiệp vụ ở Service