thảo luận [Thảo luận] Repository Pattern là cái bullsh*t nhất khi đã có ORM framework?

andinhtien · 20/12/25

Theo e thấy thì cả bác Frog và các bác kia đều có ý đúng, nhưng em bổ sung thêm 1 góc nhìn support cho việc dùng repository pattern khi dự án dùng ORM là layer Repository mang lại lợi ích trong việc đóng vai trò là 1 layer bọc bussinesslogic.

HIểu đơn giản là ORM bọc technical, còn Repo bọc nghiệp vụ. Rõ ràng nếu là 1 SA hay dev bác không muốn đem cục này ở khắp nơi

_dbContext.Invoices
.Where(x => x.TaxEntityId == taxEntityId
&& x.Status != 1
&& x.IssueDate >= from
&& x.IssueDate <= to);

Thay vì chỉ cần

invoiceRepository.GetInvoicesInPeriod();

1 cái expose Iqueryable<> còn 1 cái expose business intent. Với 1 dự án chỉ crud vài chục bảng thì không sao nhưng nếu dự án có nghiệp vụ phức tạp chút theo em là khác biệt rõ ràng đấy.

Chưa kể việc mock _dbContext để unitest cũng có cả tỷ vấn đề khi mock các dbset và return iqueryable<>, trong khi cái em cần ở unit test là test business logic, em chỉ cần mock result cho repository là được.

CHung quy lại thì pattern nào cũng có ưu nhược điểm và luôn phải trade-off thôi. Không có đúng sai mà chỉ có phù hợp hay không thôi.

GeniVN · 20/12/25

còn 1 use case nữa là khi DB setup phức tạp, như sharding, partition và muốn abstract khỏi business logic

1457040007 · 22/12/25

andinhtien đã nói:
Theo e thấy thì cả bác Frog và các bác kia đều có ý đúng, nhưng em bổ sung thêm 1 góc nhìn support cho việc dùng repository pattern khi dự án dùng ORM là layer Repository mang lại lợi ích trong việc đóng vai trò là 1 layer bọc bussinesslogic.

HIểu đơn giản là ORM bọc technical, còn Repo bọc nghiệp vụ. Rõ ràng nếu là 1 SA hay dev bác không muốn đem cục này ở khắp nơi

1 cái expose Iqueryable<> còn 1 cái expose business intent. Với 1 dự án chỉ crud vài chục bảng thì không sao nhưng nếu dự án có nghiệp vụ phức tạp chút theo em là khác biệt rõ ràng đấy.

Chưa kể việc mock _dbContext để unitest cũng có cả tỷ vấn đề khi mock các dbset và return iqueryable<>, trong khi cái em cần ở unit test là test business logic, em chỉ cần mock result cho repository là được.

CHung quy lại thì pattern nào cũng có ưu nhược điểm và luôn phải trade-off thôi. Không có đúng sai mà chỉ có phù hợp hay không thôi.

invoiceRepository.GetInvoicesInPeriod();
Repository thuộc infrastructure layer thì sao lại chứa GetInvoicesInPeriod() thuộc về domain được bác.

invoiceDomain.GetInvoicesInPeriod(); thì nó sẽ rõ ràng hơn. Giả sử GetInvoicesInPeriod là nghiệp vụ mà lại nằm trong repo thì invoiceDomain đang không mô tả đầy đủ business logic của nó và
GetInvoicesInPeriod() đang nằm ở vùng xám của Domain layer và Infrastructure layer

Tiểu Màn Thầu BK · 22/12/25

Như e đang làm có case này do thiết kế db lỏ mà ko dùng repository code nó dài ngoằng. Giả sử có bảng Category chứa các record cũng như các version của nó trong đó. Muốn lấy ra version hiện tại của 1 record nào phải viết đoạn query khá dài vì phải join do .net cũ quá ko xài đc window function. Giờ đoạn ấy ko viết 1 hàm trong repo rồi dùng lại mà đẩy code lên chỗ services chắc e xỉu mất

GeniVN · 22/12/25

1457040007 đã nói:
invoiceRepository.GetInvoicesInPeriod();
Repository thuộc infrastructure layer thì sao lại chứa GetInvoicesInPeriod() thuộc về domain được bác.

invoiceDomain.GetInvoicesInPeriod(); thì nó sẽ rõ ràng hơn. Giả sử GetInvoicesInPeriod là nghiệp vụ mà lại nằm trong repo thì invoiceDomain đang không mô tả đầy đủ business logic của nó và
GetInvoicesInPeriod() đang nằm ở vùng xám của Domain layer và Infrastructure layer

fen cứ nghĩ đơn giản thôi. Repository là 1 nơi chứa query thuộc cái domain fen đang code. Invoices thì InvoiceRepository để câu GetInvoicesInPeriod là chuẩn rồi. Giả sử GetInvoicesInPeriod có thể cache được, hay phải query trên nhiều partition, shard, etc. thì nó phải nằm ở Repository để những thằng Service khác dùng được chứ k để chung, chạy thẳng DbContext hay ORM gì đó được, thế thì cái service nó bát nháo cực kỳ

fen cứ nghĩ Repository là lớp truy vấn dữ liệu của 1 domain cụ thể thì cái ý của fen trên make sense liền

1457040007 · 22/12/25

Tiểu Màn Thầu BK đã nói:
Như e đang làm có case này do thiết kế db lỏ mà ko dùng repository code nó dài ngoằng. Giả sử có bảng Category chứa các record cũng như các version của nó trong đó. Muốn lấy ra version hiện tại của 1 record nào phải viết đoạn query khá dài vì phải join do .net cũ quá ko xài đc window function. Giờ đoạn ấy ko viết 1 hàm trong repo rồi dùng lại mà đẩy code lên chỗ services chắc e xỉu mất

viết trong service luôn, wrap toàn bộ query trong private method của service class là được mà. :rolleyes:

GeniVN · 22/12/25

1457040007 đã nói:
viết trong service luôn, wrap toàn bộ query trong private method của service class là được mà.

vậy thì nó lại khó test. Fen xài mock db hay testcontainer dc thì k nói

Tiểu Màn Thầu BK · 22/12/25

1457040007 đã nói:
viết trong service luôn, wrap toàn bộ query trong private method của service class là được mà.

Case của e nó giống như bác GeniVN nói ở trên đó, dùng nhiều service nên viết vào repo gọn hơn

smileHun · 2/1/26

Nevermind_1102_v2 đã nói:
1. RP nó sinh ra méo phải cho việc đổi db
2. Chuyện đổi db là hoàn toàn có thể xảy ra, tất nhiên k phsir biến. Ví dụ dùng oracle xong sau nhiều năm tốn tiền quá -> move sang postgres, đổi 1 phần relation db sang nosql…
3. Mục đích chính của RP nó là tập trung domain logic lại 1 chỗ, tách domain service ra khỏi persistance,
4. Code lặp lại những gì ORM đã làm như get, getAll, save, update -> đây là do bad implement chứ k phải do bản thân RP
5. Quản lý transaction nên đc thực hiện ở tầng service, nếu ném vào repository thì là bad practice cmnr
Thôi ngại type tiếp quá, nhưng mà đây cũng là những cái ngày xưa tôi nghĩ về RP mà sau này lên SA mới clear hết đc

via theNEXTvoz for iPhone

bac co the share mot vai repo implement ngon dc k bac

fkphua3 · 6/3/26

Kân team v2 đã nói:
tôi add thêm rồi đó. Nói chung đây là 1 kiểu như insurance cho các thay đổi trong tương lai ấy. Có thể bây giờ anh thấy bullshit nhưng 5 năm 10 năm mấy thằng khác vật vã thì anh phẻ re. Có lẽ người ta ko biết tương lai nó thay đổi yêu cầu gì, nên xài cái generic nhất để đón đầu thoy

ví dụ anh viết sql cho mysql only, thằng lead đòi orm cho mọi loại sql, anh chửi vẽ chuyện, nhưng tương lai 10 năm nữa oracle nó giết mysql lại phải đổi sang postgres thì sao, orm nó đỡ cho anh hết. Lúc thay đổi đó anh ko phải chuyển code mysql trong 10 năm đó thành code postgresql. Cái repo pattern này có lẽ tương tự.

Bác tiên đoán cũng ghê đấy thằng oracle sút nguyên team code mysql rồi

Hiro San · 8/3/26

Lần cuối các bác thực sự đổi database là khi nào vậy (ví dụ case simple nhất từ Postgres sáng MySQL), tôi thì chưa gặp nên chưa có kn.

never_can_tell_1 · 9/3/26

andinhtien đã nói:
Theo e thấy thì cả bác Frog và các bác kia đều có ý đúng, nhưng em bổ sung thêm 1 góc nhìn support cho việc dùng repository pattern khi dự án dùng ORM là layer Repository mang lại lợi ích trong việc đóng vai trò là 1 layer bọc bussinesslogic.

HIểu đơn giản là ORM bọc technical, còn Repo bọc nghiệp vụ. Rõ ràng nếu là 1 SA hay dev bác không muốn đem cục này ở khắp nơi

1 cái expose Iqueryable<> còn 1 cái expose business intent. Với 1 dự án chỉ crud vài chục bảng thì không sao nhưng nếu dự án có nghiệp vụ phức tạp chút theo em là khác biệt rõ ràng đấy.

Chưa kể việc mock _dbContext để unitest cũng có cả tỷ vấn đề khi mock các dbset và return iqueryable<>, trong khi cái em cần ở unit test là test business logic, em chỉ cần mock result cho repository là được.

CHung quy lại thì pattern nào cũng có ưu nhược điểm và luôn phải trade-off thôi. Không có đúng sai mà chỉ có phù hợp hay không thôi.

Nếu ko muốn đẩy 1 cục đi khắp nơi thì mình có thể cho xuống Application layer mà gọi. Và nếu Repo chỉ để bọc business logic, thì nói thật là chẳng cần nó cũng có thể làm được, quan trọng người code là ai.

Về việc test, mình nghĩ quan trọng là cách bạn xây dựng hệ thống test thế nào. Như cá nhân mình, nếu đã dùng ORM thì build thêm luôn InMemory hoặc SQLite Database local trên môi trường Dev cho việc test, và mình thấy test còn nhanh và tiện hơn nhiều. Vì mình chỉ việc đẩy vào raw data là test được ngay, chứ bạn Mock thì cái input cần để test nó là processed data rồi, cho nên ko nhanh được, ko cẩn thận vớ vẩn data để test còn sai nữa ấy chứ.

thảo luận [Thảo luận] Repository Pattern là cái bullsh*t nhất khi đã có ORM framework?

Có nên sử dụng repository pattern khi đã có ORM framework rồi ko?

Có - có lợi nhiều lắm để tôi cmt bên dưới

Có - thấy người ta hay xài thì mình xài thôi (chắc là cũng có lợi gì đó nhưng dek biết)

Không - tốn công vô ích, đẽ ra cho thêm việc phức tạp chứ ko lợi lộc gì đáng kể

Không - code nhiều mệt vãi, xài trực tiếp ORM cho nhanh (cũng ko biết là có lợi hay ko)

Tuỳ - tuỳ dự án, tuỳ yêu cầu

andinhtien

Senior Member

GeniVN

Senior Member

1457040007

Senior Member

Tiểu Màn Thầu BK

Senior Member

GeniVN

Senior Member

1457040007

Senior Member

GeniVN

Senior Member

Tiểu Màn Thầu BK

Senior Member

smileHun

Senior Member

fkphua3

Senior Member

Hiro San

Senior Member

never_can_tell_1

Senior Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này