Vâng bác, sau khi làm xong MVVM e hiểu rằng Repository quan trọng ntn rồi
thảo luận [Thảo luận] Repository Pattern là cái bullsh*t nhất khi đã có ORM framework?
- Thread starter Pepe.The.Frog
- Start date
Lev.nam
Junior Member
đồng ý với thím cuoc_song.
nhân tiện tôi thấy topic hay nên đưa ra một chút ý kiến:
một số ORM framework cho phép tận dụng entity kết hợp với kế thừa generic class để tạo ra repository, vẫn có thể sử dụng những method đã có sẵn của entity và tạo thêm custom method khi cần thiết ở trong repository
có lẽ do ORM framework của thớt không support tốt vụ này thôi
nhân tiện tôi thấy topic hay nên đưa ra một chút ý kiến:
một số ORM framework cho phép tận dụng entity kết hợp với kế thừa generic class để tạo ra repository, vẫn có thể sử dụng những method đã có sẵn của entity và tạo thêm custom method khi cần thiết ở trong repository
có lẽ do ORM framework của thớt không support tốt vụ này thôi
Daibac6996
Junior Member
Ông nào làm .Net có thể tham khảo cái code này https://github.com/dotnet-architecture/eShopOnWeb xem bọn MS nó hướng dẫn cái architecture như thế nào. Có cả ebook, có giải thích về repository https://docs.microsoft.com/en-us/do...ps-azure/common-web-application-architectures
Ông @Pepe.The.Frog đọc đi rồi chửi chết cụ bọn MS nhé
Ông @Pepe.The.Frog đọc đi rồi chửi chết cụ bọn MS nhé
vominhtrius
Senior Member
Đồng ý với bác, thằng nestjs có support vụ này, và tôi kết hợp cả 2, cái nào đơn giản thì tôi xài trực tiếp orm, còn phức tạp thì tạo repo extend từ generic.
kulboy_vn
Senior Member
tôi vẫn thích custom orm hơnAnh tự viết Repository Pattern từ đầu với anh custom ORM để support cloud/xml/nosql là NHƯ NHAU!
Cái lợi của việc sử dụng trực tiếp ORM là tận dụng được đầy đủ chức năng của ORM đó, chứ ko phải mổi lần cần lại abstract nó lên repository.
Những dự án xài repository thì thấy toàn là khổ trước chứ lúc sướng thì thật sự tôi chưa thấy. Tới lúc cần đổi thì các anh re-implement lại repository cũng sml chứ ở đó mà sướng. Effort bỏ ra cũng y như custom ORM.
))ModelEntity.Instance.CreatQuery().where....ToList()
)
kulboy_vn
Senior Member
Không liên quan - nhưng các thím sử dụng thằng SQLsugar của pháp sư trung hoa chưa?Vậy khai sáng cho tôi đi anh. Thật sự tôi rất muốn biết anh có cái yêu cầu "thần thánh" nào mà ngay cả cái ORM nổi tiếng như Entity Framework của Microsoft cũng ko đáp ứng được anh.
Nếu thế thì anh tạo 1 cái framework riêng đạp đổ hàng Microsoft hay Hiberanate luôn đi.
Chứ nãy giờ các anh nói chung chung là có lợi nhưng đíu đưa dc cái ví dụ cụ thể nào. Vì thật sự vừa nghĩ tới thì nghĩ lại thằng ORM nó cũng làm dc luôn rồi.
Hay phết
Quan điểm của tôi về Repository pattern nó như này:
Định nghĩa: nơi đóng gói các phương thức liên quan đến việc access db => ở đây chỉ có các tác vụ liên quan đến việc access db (persistence layer). Có thể ném cái này vào service được không? được. Gọi nó là DAO có được không? Cũng được luôn.
ORM Java có Hibernate, .NET có EF, 2 thằng này đều có sẵn các method liên quan đến data access nên việc CÓ CẦN THIẾT PHẢI DÙNG Repository không? KHÔNG. Nhưng với những ai đã quen lối viết Repository, hoặc MUỐN VIẾT RÕ RÀNG các action liên quan đến Data access ra thì sao? Thì dùng Repository.
Chốt lại, Repository nó không phải thứ BẮT BUỘC PHẢI CÓ một khi đã có ORM. Nhưng nếu muốn nó rõ ràng (và thi thoảng là lười nữa, ví dụ như khi dùng JpaRepo) thì dùng Repo cũng được.
Bảo nó bullshit? không. Bảo nó là 1 thứ sinh ra từ ORM, đúng. Với tôi nó là 1 trong số các triển khai của KỸ THUẬT ORM (not an ORM Framework implementation)
Định nghĩa: nơi đóng gói các phương thức liên quan đến việc access db => ở đây chỉ có các tác vụ liên quan đến việc access db (persistence layer). Có thể ném cái này vào service được không? được. Gọi nó là DAO có được không? Cũng được luôn.
ORM Java có Hibernate, .NET có EF, 2 thằng này đều có sẵn các method liên quan đến data access nên việc CÓ CẦN THIẾT PHẢI DÙNG Repository không? KHÔNG. Nhưng với những ai đã quen lối viết Repository, hoặc MUỐN VIẾT RÕ RÀNG các action liên quan đến Data access ra thì sao? Thì dùng Repository.
Chốt lại, Repository nó không phải thứ BẮT BUỘC PHẢI CÓ một khi đã có ORM. Nhưng nếu muốn nó rõ ràng (và thi thoảng là lười nữa, ví dụ như khi dùng JpaRepo) thì dùng Repo cũng được.
Bảo nó bullshit? không. Bảo nó là 1 thứ sinh ra từ ORM, đúng. Với tôi nó là 1 trong số các triển khai của KỸ THUẬT ORM (not an ORM Framework implementation)
Vozer cấp tiến
Member
Các thím cho mình hỏi, mask dữ liệu lại thì là ở tầng nào ạ?
Ý bạn là mask thế nào? Nếu tránh để lộ sensitive info trong log thì cấu hình mấy cái log framework là được. Còn mask password hay user info này nọ thì bỏ vào services.
Vozer cấp tiến
Member
Tức là ở tầng storage, thao tác với dữ liệu mình encrypt id, dữ liệu cần mask à thím?
Vậy khi mình gửi id đc mã hoá từ client lên, thì decrypt ở tầng nào ạ? Hay cũng service luôn?
QTQTQT
Member
Thím phải biết mask dữ liệu với đội tượng nào, ở layer nào thì mới xử lý được chứ.
Vozer cấp tiến
Member
Mask id là một, mask dữ liệu theo role là hai ạ.
BanhXe0_
Đã tốn tiền
Tôi chưa đọc hết thớt vì có thể toàn gạch anh(sẽ đọc), nhưng đầu tiên thì tôi đứng vê phía thớt trong việc bỏ Repository nếu dùng ORM , nhất là bọn session như Hibernate hay SQLalchemy, về bản chất session trong bọn này chính là Unit of work rồi, chúng ta chỉ gọi session chứ có biết mẹ gì phía sau cái ORM nó làm gì đâu.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.
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)
Update:
Để tránh mọi sự hiểu lầm tôi đang nói cụ thể cách Implement Repository Pattern sử dụng Generic Repository như trong link này là bullshit khi đã có ORM:
https://docs.microsoft.com/en-us/as...f-work-patterns-in-an-asp-net-mvc-application
Theo cách dùng Generic Repository như này thì mổi repo tương ứng 1-1 với Entity. Lúc này nó implement ngu là ko có abstract ra IQueryable nên ko join/query đươc. Và quan trọng là useless vì đã có Ef rồi.
Còn anh nào implement Repository xem như Data Access Class trong mô hình 3 layers cổ điển thì tôi ko tranh cãi vì bản chất 2 design support 2 chuyện khác nhau:
1. Generic Repository là để abstract luôn cả cách query/update data cho từng entity type /table riêng lẽ. (việc mà ngày xưa chưa có ORM mới phải làm).
2. Data Access Class (trong 3 layers) là để gom các query logic, business rules. Dự án anh nào lớn thì xài 3 layers, dự án nào nhỏ thì xài 2 layers nhưng điểm chung là đều sử dụng ORM như dbContext, Hibernate session. Nhiều anh sử dụng tên DAL class là Repository luôn nên dễ hiểu lầm với cái implement Generic Repository kia.
https://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework-core/
View attachment 1011739
BanhXe0_
Đã tốn tiền
Tôi chưa dùng Hibernate , nhưng vẻ bôi đậm là eager load
xshatter
Senior Member
mask hiện tại đang để ở application lẫn orm. Mấy cái nhạy cảm nên để orm nó che hộ.
xshatter
Senior Member
tui cũng thấy hơi lạ khi Repo lại wrap cái UoW, sao ko để Domain Model nó xài trực tiếp UoW cho mọi ch nó nhẹ nhàng bớt
Vozer cấp tiến
Member
Cảm ơn thím, mấy object đơn giản thì mask tầng trên, nested object mình mask ở orm, sợ không đúng chức năng.
crazy old man
Senior Member
Pv laravel được hỏi có dùng repo không bảo không thế là họ bảo luôn chắc các dự án đã làm đều nhỏ phải không ?.
Reishou
Senior Member
Có rớt cũng không cần quá tiếc, chỉ mấy con gà mới thở ra được câu đó thôi, có vào làm cũng không học hỏi được gì đâu
Similar threads
