Khang.Hy.Gia.222
Member
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
))
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
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
))
Khang.Hy.Gia.222
Member
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
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.
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. 
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.
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.
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
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ì:
- Nếu xài Repository: -> Re-implement lại Repository bỏ đi cái EF, xài cái mới
- Nếu ko xài Repository -> Re-implement lại Service bỏ đi cái EF, xài cái mớ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
@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 
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.
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.
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.
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.
Đã 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
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
Last edited:
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
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
Daibac6996
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ìĐã 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
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
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àyOff 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
Mot nhan cach tot
Junior Member
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?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)
https://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework-core/
View attachment 1011739
Tôi nhắc nhẹ thôi, các anh cẩn thận mồm miệng.
Debate thoải mái nhưng nói tục thì … hm
Thế nhé, ngôn ngữ chợ búa vui lòng đi nơi khác.
Tiếp đi các anh
Debate thoải mái nhưng nói tục thì … hm
Thế nhé, ngôn ngữ chợ búa vui lòng đi nơi khác.
Tiếp đi các anh
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..”
via theNEXTvoz for iPhone
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..”
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.
Pepe.The.Frog
Senior Member
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.
Similar threads
