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

cuoc_song said:

@Pepe.The.Frog anh trả lời cái câu này của tôi đi

Click to expand...

Tôi đồng ý với ý kiến của anh @superuser@ . Custom ORM là 1 cách. Ko biết làm cách nào thì anh post code cái cách a làm bằng repository pattern lên đây, tôi sẽ làm lại y chan mà chỉ cần dùng ORM. Vậy ok chưa?

Còn chuyện đảm bảo để developer ko gọi sai là thuộc về code review. Anh dùng Repository Pattern cũng ko tránh đươc.

levinhtin said:

Là sao bác, vậy vẫn phải viết Repository + ORM là đúng hay sai.

Click to expand...

1. Repository + ORM là sai
2. Trường hợp Dapper thì nó ko phải là 1 ORM đầy đủ

Anh đang hiểu lầm Dapper là 1 ORM đầy đủ. Bản chất thằng Dapper ko phải là 1 ORM đúng nghĩa, nó chỉ là micro-ORM. Nó chỉ là extensions của Ado.Net thôi nên tôi xem đây là trường hợp ko sử dụng ORM.

Dapper ko có 1 abstraction đầy đủ của 1 ORM để có thể tự do custom loại database hay storage khác như ORM. Ví dụ viết draw SQL muốn đổi qua NoSQL thì ko có interface để custom.



Các anh thấy thằng ORM nó có hết những gì cái Repository mà các anh tự build chưa.

Cá nhân tôi vẫn KHÔNG lựa chọn sử dụng Repository Pattern khi xài Dapper vì cân nhắc mức độ phức tạp tào lao khi build thằng củ nồi này với lợi ích mang lại là ko đáng. Tôi chấp nhận xài trực tiếp SqlConnection của Ado. Rồi chổ nào cần lấy data từ nới khác thì tôi build Interface/Service riêng cho chổ đó thôi.

superuser@ said:

ORM hay Repo pattern đều ko đảm bảo. Data xử lý của cả 2 đều là dùng API từ db thì làm sao đảm bảo đc pk bạn?

Cách làm của bạn là ko expose API update/delete, cách này đâu đủ mạnh để đảm bảo cho yêu cầu. Vấn đề nằm ở 2 chỗ: 1 là code review, 2 là db Grant. Theo tôi là vậy.

Click to expand...

Sao lại không đảm bảo vậy anh ? Dev của dự án là cần thực hiện cái nghiệp vụ như tôi mô tả và dev chỉ truy cập DB qua connection string. Code review tôi chỉ cần review interface là đủ để đảm bảo bọn nó đang thực hiện đúng cái nghiệp vụ này. Còn nếu dùng ORM thôi thì khác gì thả gà ra đuổi, làm sao mà review hết mọi chỗ dùng cái bảng History này được.

Trong trường hợp anh chỉ động vào code mà ko được can thiệp vào DB thì anh chỉ giúp tôi là nếu làm bằng Repo thì nó sẽ update bảng History bằng cách nào ?

cuoc_song said:

Sao lại không đảm bảo vậy anh ? Dev của dự án là cần thực hiện cái nghiệp vụ như tôi mô tả và dev chỉ truy cập DB qua connection string. Code review tôi chỉ cần review interface là đủ để đảm bảo bọn nó đang thực hiện đúng cái nghiệp vụ này. Còn nếu dùng ORM thôi thì khác gì thả gà ra đuổi, làm sao mà review hết mọi chỗ dùng cái bảng History này được.

Trong trường hợp anh chỉ động vào code mà ko được can thiệp vào DB thì anh chỉ giúp tôi là nếu làm bằng Repo thì nó sẽ update bảng History bằng cách nào ?

Click to expand...

Tôi nói ở trên đấy.

Bạn cho dev truy cập vào db thì bạn phải review code. Còn ORM hay Repo gì thì dev có privileged nó làm được hết rồi còn gì.

Còn muốn đảm bảo 100% ko update/delete đc bạn phải dùng DB Grant/Lock thôi.

Để chắn ăn hơn, thì làm cả 2: Vừa review code, vừa grant db. Bạn đã thấy là cái yêu cầu no update/ delete nó chẳng phụ thuộc gì vào Repo hay ORM hay chưa?

Thậm chi ORM nó lock rows còn dễ hơn repo của bạn.

Haizz cãi với cái anh trên kia ảnh chưa hiểu vấn đề.

Chắc anh xài ORM chỉ biết mổi CRUD chứ đâu biết ORM nó support tận răng từ read only connection, cache, unit of work, database migrations…

Thế nên hôm nay tôi vào chửi để các anh đừng có đi PHÁT MINH LẠI CÁI BÁNH XE nữa!

via theNEXTvoz for iPhone

Thật ra để làm cho đúng với câu chuyện "historical data" thì rất mất thời gian và công sức, chuyện Repo/ORM chỉ là 1 quan tâm rất nhỏ.

Historical records của 1 loại data nó có thể grow rất nhanh, rất mạnh, vài trăm triệu tới tỷ tỷ. Ngta thường dùng replication db để đáp ứng cho historical data. Và tất nhiên Replication thì ReadOnly, đây mới là cách đúng để làm chứ giấu diếm cái API update/delete là 1 cách tiếp cận rất sai.

Thôi các anh đọc document đi
https://docs.microsoft.com/en-us/do...terns/infrastructure-persistence-layer-design

Tôi gộp 3 gạch cuối của nó ở đây

1. The Repository pattern makes it easier to test your application logic​

2. The difference between the Repository pattern and the legacy Data Access class (DAL class) pattern​

3. Repositories shouldn't be mandatory <=== chú ý nhé​

Nói chúng các anh ko quan tâm đến DDD hoặc microservices thì bỏ qua. Hoặc application của các anh ko yêu cầu đến mức đó thì bỏ qua nó đi.

Tôi thấy tranh cãi vô nghĩa vcl

superuser@ said:

Tôi nói ở trên đấy.

Bạn cho dev truy cập vào db thì bạn phải review code. Còn ORM hay Repo gì thì dev có privileged nó làm được hết rồi còn gì.

Còn muốn đảm bảo 100% ko update/delete đc bạn phải dùng DB Grant/Lock thôi.

Để chắn ăn hơn, thì làm cả 2: Vừa review code, vừa grant db. Bạn đã thấy là cái yêu cầu no update/ delete nó chẳng phụ thuộc gì vào Repo hay ORM hay chưa?

Thậm chi ORM nó lock rows còn dễ hơn repo của bạn.

Click to expand...

Mệt thế. Tôi có bảo ko phải review code đâu. Nhưng cái cách tôi review code khác với cái anh review code. Và tôi bảo là nếu dùng repo thì tôi kiểm soát qua các interface về cơ bản là đủ. Chứ mỗi lần có change request tôi phải đi review hết chỗ này đến chỗ kia thì làm sao đỡ được.

Cái Repo pattern này nó là 1 pattern. Nó phải nằm trong 1 ngữ cảnh cụ thể để phát huy tác dụng của nó. Ở đây là tôi dùng kết hợp ORM để làm những cái việc ORM sẽ khó làm hoặc phức tạp như

• Giới hạn chức năng
• Gom nhóm nghiệp vụ của ORM để tránh lặp code
• Bổ sung các feature như cache hoặc thậm chí đổi qua raw sql cho 1 function nào đó nếu cần high performance.

Còn việc anh ko thích dùng Repo pattern thì cứ không dùng chứ có làm sao đâu.

joonkim said:

Thôi các anh đọc document đi
https://docs.microsoft.com/en-us/do...terns/infrastructure-persistence-layer-design

Tôi gộp 3 gạch cuối của nó ở đây

1. The Repository pattern makes it easier to test your application logic​

2. The difference between the Repository pattern and the legacy Data Access class (DAL class) pattern​

3. Repositories shouldn't be mandatory <=== chú ý nhé​

Click to expand...

Cái post trên Microsoft cũng chưa chắc là đúng đâu anh. Mấy thánh này cũng bị chửi sml đấy

1. ORM cũng support chuyện mock và test
2. Ko liên quan vì tôi đang bàn giữa Repository Pattern và ORM. Với tôi chỉ nên chọn thằng ORM là đủ. Ko bàn chuyện legacy data access class.
3. Cũng ko liên quan, vì tất nhiên xài thế nào là tuỳ dự án nhưng cái TÀO LAO là nếu đã chọn xài ORM thì ko cần phải xài Repository Pattern nữa.

via theNEXTvoz for iPhone

Có cái này hơi fun tí, nhiều người cũng chửi sml ORM đòi dùng raw-query

cuoc_song said:

Mệt thế. Tôi có bảo ko phải review code đâu. Nhưng cái cách tôi review code khác với cái anh review code. Và tôi bảo là nếu dùng repo thì tôi kiểm soát qua các interface về cơ bản là đủ. Chứ mỗi lần có change request tôi phải đi review hết chỗ này đến chỗ kia thì làm sao đỡ được.

Cái Repo pattern này nó là 1 pattern. Nó phải nằm trong 1 ngữ cảnh cụ thể để phát huy tác dụng của nó. Ở đây là tôi dùng kết hợp ORM để làm những cái việc ORM sẽ khó làm hoặc phức tạp như

• Giới hạn chức năng
• Gom nhóm nghiệp vụ của ORM để tránh lặp code
• Bổ sung các feature như cache hoặc thậm chí đổi qua raw sql cho 1 function nào đó nếu cần high performance.

Còn việc anh ko thích dùng Repo pattern thì cứ không dùng chứ có làm sao đâu.

Click to expand...

Tôi thì chỉ cần review code là đủ, tôi review rất kỹ line by line, block by block. Naming sai tôi bắt đổi cho sát nghĩa, empty space tôi cũng bắt remove, nên chuyện update/delete vớ vẩn tôi khá tự tin là ko có.

Ngoài ra thì tôi tin dùng replication db cho historical data, grant đúng permission cho dev, chứ code pattern với tôi là chưa đủ mạnh.

cuoc_song said:

Mệt thế. Tôi có bảo ko phải review code đâu. Nhưng cái cách tôi review code khác với cái anh review code. Và tôi bảo là nếu dùng repo thì tôi kiểm soát qua các interface về cơ bản là đủ. Chứ mỗi lần có change request tôi phải đi review hết chỗ này đến chỗ kia thì làm sao đỡ được.

Cái Repo pattern này nó là 1 pattern. Nó phải nằm trong 1 ngữ cảnh cụ thể để phát huy tác dụng của nó. Ở đây là tôi dùng kết hợp ORM để làm những cái việc ORM sẽ khó làm hoặc phức tạp như

• Giới hạn chức năng
• Gom nhóm nghiệp vụ của ORM để tránh lặp code
• Bổ sung các feature như cache hoặc thậm chí đổi qua raw sql cho 1 function nào đó nếu cần high performance.

Còn việc anh ko thích dùng Repo pattern thì cứ không dùng chứ có làm sao đâu.

Click to expand...

A đọc lại #65.

via theNEXTvoz for iPhone

joonkim said:

Nói chúng các anh ko quan tâm đến DDD hoặc microservices thì bỏ qua. Hoặc application của các anh ko yêu cầu đến mức đó thì bỏ qua nó đi.

Tôi thấy tranh cãi vô nghĩa vcl

Click to expand...

Nó có ý nghĩa ở chổ là ORM nó đã làm tất cả những gì mà anh định làm khi build Repository Pattern. Tôi chửi cho các anh sáng mắt ra mà đừng đi PHÁT MINH LẠI BÁNH XE nữa!

Tôi cũng đang làm DDD và microservices đây và nó chẳng liên quan chuyện có nên xài Repository Pattern hay ko.

Pepe.The.Frog said:

A đọc lại #65.

via theNEXTvoz for iPhone

Click to expand...

Tôi dụng ORM rất nhiều là đằng khác. Mấy cái anh chỉ tôi cũng dùng hết rồi, thư viện hỗ trợ EF Extension tôi cũng mua, tự viết thêm thư viện bổ sung cho EF cũng có. Nhưng với tôi nó vẫn là chưa đủ và tôi cần thêm Repo để hỗ trợ.

Vậy nên tôi mới bảo việc dùng Repo hay không là do anh. Anh thấy không cần thì không dùng, tôi thấy cần thì tôi dùng.

cuoc_song said:

Tôi dụng ORM rất nhiều là đằng khác. Mấy cái anh chỉ tôi cũng dùng hết rồi, thư viện hỗ trợ EF Extension tôi cũng mua, tự viết thêm thư viện bổ sung cho EF cũng có. Nhưng với tôi nó vẫn là chưa đủ và tôi cần thêm Repo để hỗ trợ.

Vậy nên tôi mới bảo việc dùng Repo hay không là do anh. Anh thấy không cần thì không dùng, tôi thấy cần thì tôi dùng.

Click to expand...

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.

Pepe.The.Frog said:

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.

Click to expand...

Anh nhét chữ vào mồm quá. Đoạn nào tôi bảo là tạo cái framework riêng thay thế cho hàng Microsoft. Tôi nhấn mạnh lại là tôi dùng ORM bên trong Repo luôn và tôi rất thích dùng EF cho anh khỏi lằng nhằng.

Còn cụ thể thì cafe đi chứ tôi quá lười viết 1 bài siêu dài trên này để giải thích việc tôi dùng Repo thế nào và tại sao tôi nên dùng Repo

cuoc_song said:

Anh nhét chữ vào mồm quá. Đoạn nào tôi bảo là tạo cái framework riêng thay thế cho hàng Microsoft. Tôi nhấn mạnh lại là tôi dùng ORM bên trong Repo luôn và tôi rất thích dùng EF cho anh khỏi lằng nhằng.

Còn cụ thể thì cafe đi chứ tôi quá lười viết 1 bài siêu dài trên này để giải thích việc tôi dùng Repo thế nào và tại sao tôi nên dùng Repo

Click to expand...

Tôi hiểu cái mô hình của a đang là như này:
Controllers -> Services -> Repositories -> ORM

Còn theo tôi nó nên là như này:
Controllers -> Services -> ORM

Lý do tôi chửi là vì tôi thấy rất nhiều dự án đã xài ORM rồi còn chèn thêm thằng Repositories bên trên như anh với rất nhiều lý do mơ hồ đưa ra nhưng khi tôi xoáy vào cụ thể vì sao mô hình phía dưới ko đáp ứng đc thì chẳng ai trả lời dc.

Khi nào rảnh thì a demo 1 phát cho tôi mở mang tầm mắt chứ gặp Vozer ngoài đời ngại lắm, ko dám gặp đâu.

Pepe.The.Frog said:

Tôi hiểu cái mô hình của a đang là như này:
Controllers -> Services -> Repositories -> ORM

Còn theo tôi nó nên là như này:
Controllers -> Services -> ORM

Lý do tôi chửi là vì tôi thấy rất nhiều dự án đã xài ORM rồi còn chèn thêm thằng Repositories bên trên như anh với rất nhiều lý do mơ hồ đưa ra nhưng khi tôi xoáy vào cụ thể vì sao mô hình phía dưới ko đáp ứng đc thì chẳng ai trả lời dc.

Khi nào rảnh thì a demo 1 phát cho tôi mở mang tầm mắt chứ gặp Vozer ngoài đời ngại lắm, ko dám gặp đâu.

Click to expand...

Cãi nhau khá mất thời gian. Hẹn anh 9h tối nay call meet để demo thôi.

Pepe.The.Frog said:

Cái post trên Microsoft cũng chưa chắc là đúng đâu anh. Mấy thánh này cũng bị chửi sml đấy

1. ORM cũng support chuyện mock và test
2. Ko liên quan vì tôi đang bàn giữa Repository Pattern và ORM. Với tôi chỉ nên chọn thằng ORM là đủ. Ko bàn chuyện legacy data access class.
3. Cũng ko liên quan, vì tất nhiên xài thế nào là tuỳ dự án nhưng cái TÀO LAO là nếu đã chọn xài ORM thì ko cần phải xài Repository Pattern nữa.

via theNEXTvoz for iPhone

Click to expand...

Anh thấy đủ, các dự án của a ko thấy đủ những dự án khác, dev khác ko thấy đủ
Cái caching của EF tù bỏ mẹ, như project tôi làm, phần caching xử lý phức tạp, hồi đầu bọn tôi cũng chỉ xài của EF nhưng nhiều vấn đề, cuối cùng vẫn phải tạo 1 cái repository để xử lý trên ấy.
P/s : a đừng đòi tôi show code nhé, hay a thử show code của anh dùng ORM, xử lý dc hết mock test, caching cho mọi người mở mang tầm mắt xem nào.

Share các thím 1 study case apply repository. Tôi có tình huống thế này:

Trong hệ thống e-commerce, model SalesOrder của tôi gồm những property sau:

SalesOrder
-> Customer information
-> Shipping/Billing address
-> Item list

Tôi có các lớp Services xử lý business logic, nhận input đầu vào là 1 object SalesOrder. (Gồm các nghiệp vụ trừ tồn, pick hàng, đóng gói, vận chuyển logistic v.v..)

Một ngày đẹp trời, công ty tôi ký hợp đồng với 1 đối tác bên ngoài, vận hành khâu xử lý đơn hàng. Trong hợp đồng ghi rõ là công ty tôi không được phép lưu dữ liệu khách hàng, thông tin khách hàng buộc phải gọi API về xử lý.

————————

Tôi xử dụng pattern repository từ đầu, trong repository, tôi viết các logic để build 1 model SalesOrder hoàn chỉnh (bao gồm collect thông tin các property customer, address, items) với SalesOrderRepository.get(order_code) trả về 1 model SalesOrder.

Với tình huống trên, tôi có 2 trường hợp:

• Đơn hàng thường, thông tin khách hàng tôi query trực tiếp trong DB của công ty
• Đơn hàng đối tác, thông tin khách hàng tôi gọi API để fetch về

Khi apply, tôi chỉ cần update ở phần repository, các lớp service business logic không update gì.

(*) Thông tin khách hàng là dữ liệu input để xử lý, không thay đổi trong suốt quá trình vận hành.