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

    Votes: 18 18.0%
  • 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)

    Votes: 17 17.0%
  • 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ể

    Votes: 9 9.0%
  • 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)

    Votes: 16 16.0%
  • Tuỳ - tuỳ dự án, tuỳ yêu cầu

    Votes: 40 40.0%

  • Total voters
    100

Love U So Much

Senior Member
1. Tôi ko nói Repository Pattern/UnitOfWork là Sai

2. Tôi nói trường hợp rất cụ thể là khi dự án đã xài ORM rồi còn tạo Repository Pattern/UnitOfWork để đè lên nó nữa là BULLSHIT!

Các anh chửi tôi thì các anh phải đưa ra được cái lý do nên có nó. Tất cả những lý mà các a đưa ra thì thằng ORM đều làm tốt hoặc custom tốt.
bạn có cái sai là có nhiều cách để implement repository, và dùng ORM là 1 cách. có thể là chỉ để che các method khác của ORM thôi.

và bố đéo muốn dùng hết feature của ORM, thì sao?
 
Ignore làm gì bác. Ông đó hình như lương cao mà. Nghe cho vui cửa vui nhà.
lương cao nhưng ăn nói thấy k ưa nổi.
cái cố chấp bác bỏ triệt để là điểm yếu của sv ngành KT rồi, chưa thấy ai học ngành kinh tế ra mà bác bỏ mọi người 7 page :)))
 
Repository Pattern, chắc là các bạn dev Java/C# dùng nhiều trên enterprise domain.

Nhưng k phải bất kỳ nơi đâu, ngôn ngữ nào cũng xài. Nó có usecase nhé, tôi thường abstract thêm persistence layer để chứa những logics như bạn @servuskevin nói ở trên (cả 2 ví dụ). Tôi thấy nó hợp lý và dùng trong khá nhiều project, chỉ là kinh nghiệm thôi, chứ xưa h tôi còn ko biết tới nó là 1 loại pattern trong Java/C#.
tôi thì chỉ thấy ng ta tạo ra hay hay, thì mình học, chứ tôi k nghĩ nó là pattern luôn
 

gamest

Junior Member
Xin góp vui chút , tôi không code server cũng chưa dùng ef bao giờ , nhưng tôi có tìm hiểu qua.
Tôi hiểu là ở domain layer tôi muốn làm việc với các entity, và các entity này được lấy thông qua repository, entity này và model data do fw orm cung cấp nó không phải là 1, nó là ánh xạ một số trường cần thiết sang chứ không phải toàn bộ + che dấu dữ liệu.
Trường hợp thứ 2 vì lý do nào đó t không sử dụng ef nữa mà dùng cái khác, cũng như trường hợp tôi xuất phát dự án mà không sử dụng ef mà sau đó lại muốn dùng ef.
 

Pepe.The.Frog

Senior Member
Tôi cố tình khích các anh vào để kéo page đấy. Ai khó chịu thì lượn thôi. :canny:

Còn việc apply 1 cái gì đó do người ta nói mà ko hiểu bản chất vấn đề, nghĩ nó hay thì tôi chửi là code monkey ko não cũng ko oan đâu.

Mấy cái bài viết về Repository Pattern/UnitofWork như các anh đọc được đã bị lan truyền gần chục năm nay rồi.

Thời thế bây giờ ORM rất mạnh. Cái tôi muốn nói ở topic này là nên bỏ việc build Repository layer cùng với ORM đi.
 

gamest

Junior Member
Xin góp vui chút , tôi không code server cũng chưa dùng ef bao giờ , nhưng tôi có tìm hiểu qua.
Tôi hiểu là ở domain layer tôi muốn làm việc với các entity, và các entity này được lấy thông qua repository, entity này và model data do fw orm cung cấp nó không phải là 1, nó là ánh xạ một số trường cần thiết sang chứ không phải toàn bộ + che dấu dữ liệu.
Trường hợp thứ 2 vì lý do nào đó t không sử dụng ef nữa mà dùng cái khác, cũng như trường hợp tôi xuất phát dự án mà không sử dụng ef mà sau đó lại muốn dùng ef.
Ai trả lời giúp tôi với. T rất thích những group như thế này để mở mang kiến thức
 

Pepe.The.Frog

Senior Member
Xin góp vui chút , tôi không code server cũng chưa dùng ef bao giờ , nhưng tôi có tìm hiểu qua.
Tôi hiểu là ở domain layer tôi muốn làm việc với các entity, và các entity này được lấy thông qua repository, entity này và model data do fw orm cung cấp nó không phải là 1, nó là ánh xạ một số trường cần thiết sang chứ không phải toàn bộ + che dấu dữ liệu.
Trường hợp thứ 2 vì lý do nào đó t không sử dụng ef nữa mà dùng cái khác, cũng như trường hợp tôi xuất phát dự án mà không sử dụng ef mà sau đó lại muốn dùng ef.

1. Domain model và object mapping model (trong EF nó gọi là Entity) không phải là một -> Đúng vì Entity thật sự là thuộc tầng Data Access Layer. Về mặt tổ chức code có thể phân tụi nó ra 2 module và dùng AutoMapper/DTO để map 2 thằng này khi lấy data lên.

2. Trường hợp ko sử dụng EF nữa thì tất nhiên anh phải đập đi xây lại tầng Data Access layer và effort bỏ ra là như nhau giữa việc có xài Repository hay ko vì:
  1. Nếu xài Repository: -> Re-implement lại Repository bỏ đi cái EF, xài cái mới
  2. Nếu ko xài Repository -> Re-implement lại Service bỏ đi cái EF, xài cái mới
Vấn đề là logic nặng là ở tầng Data Access layer chứ Business Service khá ít nên việc tôi gọi trực tiếp EF bên trong business service cũng chẳng có gì sai và vẫn support Unit Test/Mock bình thường vì bản thân EF nó support chuyện đó rồi.

Hơn hết, việc đổi ORM là việc rất hiếm và đa số là ko đáng như tôi đã nói ở #12:
https://voz.vn/t/thao-luan-reposito...khi-da-co-orm-framework.490455/#post-15758632
 

gamest

Junior Member
1. Domain model và object mapping model (trong EF nó gọi là Entity) không phải là một -> Đúng vì Entity thật sự là thuộc tầng Data Access Layer. Về mặt tổ chức code có thể phân tụi nó ra 2 module và dùng AutoMapper/DTO để map 2 thằng này khi lấy data lên.

2. Trường hợp ko sử dụng EF nữa thì tất nhiên anh phải đập đi xây lại tầng Data Access layer và effort bỏ ra là như nhau giữa việc có xài Repository hay ko vì:
  1. Nếu xài Repository: -> Re-implement lại Repository bỏ đi cái EF, xài cái mới
  2. Nếu ko xài Repository -> Re-implement lại Service bỏ đi cái EF, xài cái mới
Vấn đề là logic nặng là ở tầng Data Access layer chứ Business Service khá ít nên việc tôi gọi trực tiếp EF bên trong business service cũng chẳng có gì sai và vẫn support Unit Test/Mock bình thường vì bản thân EF nó support chuyện đó rồi.

Hơn hết, việc đổi ORM là việc rất hiếm và đa số là ko đáng như tôi đã nói ở #12:
https://voz.vn/t/thao-luan-reposito...khi-da-co-orm-framework.490455/#post-15758632
Tks ông, nhưng ít nhất cả 2 case thì repository pattern cũng có giá trị của nó phải không. Giống như việc abstraction trong oop thôi ấy, tùy yêu cầu mà cần thiết kế open for change hay không. Nếu SA tính đến khả năng phải sửa đổi thì vẫn cần dùng, việc dùng hay không thì phải do context chứ t ko nghĩ nó là vô dụng.
 

servuskevin

Senior Member
Tôi cố tình khích các anh vào để kéo page đấy. Ai khó chịu thì lượn thôi.

@Pepe.The.Frog tui già quá rồi nên ko hiểu nổi suy nghĩ của mấy anh trẻ bây giờ.

Tui và bạn bè già của tui thì ráng sống vui vẻ, hoà đồng, tạo không khí vui vẻ để mọi người chia sẻ trao đổi, làm việc.

Còn giờ thì câu view, click bait, khích bác lẫn nhau.

Tôi không hiểu cái kiểu quái thai gì đang diễn ra bây giờ nữa.

Thời tui là sống sao để mọi người yêu thương. Còn giờ càng bị chửi càng dzui hay sao vậy?
 

Meete

Senior Member
Anh em máu quá, vô xem mà chửi nhau vậy :shame:

Sự nghiệp chục năm đi code của mình mới ngộ ra một cái cực kỳ quan trọng đó là sự cân bằng. Mềm mại ôn nhu như dòng nước, cân bằng âm dương thái cực, cái gì quá đều không tốt.

Như mình đã còm ở trên, nghệ thuật Architect phải cân bằng được các yếu tố trong project. Có những cái dùng luôn Spring JPA, có những cái phải định nghĩa Repository concept từ domain layer trước. :confident:

Việc thay đổi ORM hay thậm chí DBMS là việc hiếm trong vòng đời của một project nhưng có những trường hợp thực sự phải cần Repository concept trước.

Lấy ví dụ trong thực tế là một project mình đang triển khai. Entity nó được fetch từ nhiều source khác nhau, có thể internal từ RDBMS mà cũng có thể external từ Web Service.
Entity có nghiệp vụ nằm trong đó nên ko thể vứt nó ra chỗ khác vì gây rò rỉ domain.

202260d16062-cbeb-481c-b0eb-5b5abf7a42d4.png
 

TVoz93

Junior Member
Đã từng apply cái repository pattern này và đã từ bỏ vì theo cá nhân mình thấy:

1. Việc đổi giữa các database sql (mysql, postgresql, ...) thì ORM đã hỗ trợ. Việc đổi từ sql sang nosql là vô cùng hy hữu (phải đổi cả đống data cũ hoặc có cơ chế tận dụng đống data cũ đó mà 1 khi nghĩ đến chuyện đổi database thì lượng data cõ lẽ sẽ phải rất lớn đến nỗi database hiện tại không gánh nổi hoặc vì lý do đặc biệt khác). Để đánh đổi khả năng rất nhỏ đổi database mà ngay từ ban đầu đã phải thêm 1 layer (thêm code) thì nếu là mình mình sẽ không chọn.

2. Rất khó để flexible bằng ORM, hầu hết các ORM đều có query interface rất bá mà mình nghĩ rất khó 1 team nào có thể tự làm ngon bằng. 1 function trong repository theo thời gian có thể có nhiều nơi khác nhau sử dụng và có thể thêm bớt các param khi đó cần update lại function trong repossitory và có thể phải đổi cả những nơi đã implement function đó, nếu không muốn thêm bớt cacs param khi phát sinh thì phải viết function mới trong repository.

3. Phức tạp và rườm rà, phải apply unit of work.

4. Không liên quan đến cache như một số người nói. (?)

5. ORM cũng mock test được.

6. Khi apply aggregate pattern thì repository cũng không phải là điều bắt buộc phải có.

// Vẫn hóng thêm lý do để sử dụng repository :burn_joss_stick:
 
Last edited:

tdat00

Đã tốn tiền
@Pepe.The.Frog tui già quá rồi nên ko hiểu nổi suy nghĩ của mấy anh trẻ bây giờ.

Tui và bạn bè già của tui thì ráng sống vui vẻ, hoà đồng, tạo không khí vui vẻ để mọi người chia sẻ trao đổi, làm việc.

Còn giờ thì câu view, click bait, khích bác lẫn nhau.

Tôi không hiểu cái kiểu quái thai gì đang diễn ra bây giờ nữa.

Thời tui là sống sao để mọi người yêu thương. Còn giờ càng bị chửi càng dzui hay sao vậy?

Chắc thím 8x giống tôi, qua 9x thấy tụi nó khác nhiều rồi, đến 2k còn khác bạo nữa.

Dĩ hòa vi quý thím ơi, đi chơi ~gay~ với tôi đi :love:

Sent from Samsung SM-G973F using vozFApp
 

tien_manh_a2

Senior Member
Off topic chút, fen có biết chơi cờ vây không. Vì thấy fen nhắc đến chữ "cân bằng" là triết lý quan trọng nhất trong môn này.
Nếu fen chưa biết chơi mà hứng thú thì tìm hiểu xem, nhiều triết lý vận dụng trong cuộc sống phết.
PS: Mình cũng đi code gần chục năm, cũng làm SA mà thấy tuổi cao sức yếu sợ vật nhau không lại :big_smile:
 

Daibac6996

Junior Member
Đã từng apply cái repository pattern này và đã từ bỏ vì theo cá nhân mình thấy:

1. Việc đổi giữa các database sql (mysql, postgresql, ...) thì ORM đã hỗ trợ. Việc đổi từ sql sang nosql là vô cùng hy hữu (phải đổi cả đống data cũ hoặc có cơ chế tận dụng đống data cũ đó mà 1 khi nghĩ đến chuyện đổi database thì lượng data cõ lẽ sẽ phải rất lớn đến nỗi database hiện tại không gánh nổi hoặc vì lý do đặc biệt khác). Để đánh đổi khả năng rất nhỏ đổi database mà ngay từ ban đầu đã phải thêm 1 layer (thêm code) thì nếu là mình mình sẽ không chọn.

2. Rất khó để flexible bằng ORM, hầu hết các ORM đều có query interface rất bá mà mình nghĩ rất khó 1 team nào có thể tự làm ngon bằng. 1 function trong repository theo thời gian có thể có nhiều nơi khác nhau sử dụng và có thể thêm bớt các param khi đó cần update lại function trong repossitory và có thể phải đổi cả những nơi đã implement function đó, nếu không muốn thêm bớt cacs param khi phát sinh thì phải viết function mới trong repository.

3. Phức tạp và rườm rà, phải apply unit of work.

4. Không liên quan đến cache như một số người nói => vote dùng event để xử cache ở 1 nơi khác.

5. ORM cũng mock test được.

6. Khi apply aggregate pattern thì repository cũng không phải là điều bắt buộc phải có.

// Vẫn hóng thêm lý do để sử dụng repository :burn_joss_stick:
4. Bạn nói rõ hơn dc ko? Tôi thường chỉ xử lý invalidate băng event, chứ lúc get từ cache hay db ko rõ là dùng event kiểu gì
 

TVoz93

Junior Member
4. Bạn nói rõ hơn dc ko? Tôi thường chỉ xử lý invalidate băng event, chứ lúc get từ cache hay db ko rõ là dùng event kiểu gì
sorry thím, đúng là khi cập nhật cache mình dùng event tận dụng event làm những việc khác nữa, còn khi get thì không, nhưng cũng không xử chung 1 repo
 

Meete

Senior Member
Off topic chút, fen có biết chơi cờ vây không. Vì thấy fen nhắc đến chữ "cân bằng" là triết lý quan trọng nhất trong môn này.
Nếu fen chưa biết chơi mà hứng thú thì tìm hiểu xem, nhiều triết lý vận dụng trong cuộc sống phết.
PS: Mình cũng đi code gần chục năm, cũng làm SA mà thấy tuổi cao sức yếu sợ vật nhau không lại :big_smile:
Mình chơi cờ vua, cờ tướng thôi thím, để rảnh nghiên cứu thêm món cờ vây này :shame::sweet_kiss:
 

Mot nhan cach tot

Junior Member
Như tít. Theo tôi nó chẳng lợi lộc gì cả. Đẽ ra cho rách việc thêm. Thế mà đi dự án nào cũng thấy ng ta setup cái này.
jmEBCky.gif


Update từ #10:
Các anh đưa lý lẽ cho việc đổi databases để dùng Repository Pattern tôi càng thấy bullshit vì:

1. Bản thân ORM framework đã support rất nhiều loại database rồi.
2. Việc đổi database qua cái mới hoàn toàn mà ORM ko support như từ MSSQL sang MongoDB là cái chuyện trong thực tiễn rất hiếm xảy ra.

Chẳng có thằng điên nào đi đòi đổi db từ relation db sang Nosql chỉ bằng config cả.

Còn cái tào lao của thằng Repository Pattern mà dự án nào xài nó tôi cũng gặp là:

1. Code lặp lại những gì ORM đã làm như get, getall, save, update, delete… include.. join…
2. Khi gọi join giữa 2 repositories, hoặc cần quản lý transaction thì lại đi code lặp lại của thằng ORM. (Bullshit)
3. Toàn bộ những gì ORM support thì bị cái anh Repository Pattern này abstract lên hết nên nếu muốn xài thì phải code lặp lại, gọi lại của ORM (như vậy lại vô tình phụ thuộc vào chính ORM đó, ko còn abstract như ý tưởng ban đầu, bullshit lần 2)

https://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework-core/

:misdoubt:
View attachment 1011739


ScTzgAa.png
anh đang đặt trong cái context nào vậy? Tôi viết cái app nhỏ nhỏ xài đủ loại persistent database cùng lúc thì xài ORM gì? Rồi tôi viết webapp thì xài ORM sao?
 

Pepe.The.Frog

Senior Member
Cuối tuần, thả bait, kéo page… tôi đã nói hết những gì cần nói… giờ các a nghiền ngẫm đi nhé.

Tôi đồng ý có việc cân bằng effort và lợi ích thu dc như anh trên kia có nói.

Riêng vụ repository pattern này thì effort bỏ ra quá lớn so với lợi ích thu dc.

Nó cứ như các anh xây nhà 3 tấm nhưng tốn hơn 1 tỉ để xây cái hầm tránh bom trong thời bình vì sợ VN sẽ bị đánh bom thì có chổ mà chui xuống.

Cái tôi sợ nhất là gặp các anh trẻ trẻ, đọc dc vài cái Pattern hay hay rồi dự án nào cũng đòi apply nó trong khi bản chất vấn đề ko hiểu. Lại cãi chày cối là “tương lai nhỡ thế này thế khác”, “nhỡ đổi ORM…”, “nhỡ đổi từ MSSQL sang NoSQL..”

:go:

via theNEXTvoz for iPhone
 

huylequang210

Junior Member
thereformedprogrammer em đọc cũng nhiều. Entity Framework cũng abstracts hết mấy lệnh CRUD rồi nên mỗi entity cũng không cần 1 tầng repository nữa. Nhưng thằng Entity Framework lại không cover hết query của bussiness logic. Nên nếu có dùng repository pattern thì dùng cho bussiness rules là ổn nhất.
 
Top