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: 29 19.2%
  • 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: 25 16.6%
  • 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: 19 12.6%
  • 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: 21 13.9%
  • Tuỳ - tuỳ dự án, tuỳ yêu cầu

    Votes: 57 37.7%

  • Total voters
    151
IQueryable là abstraction để query data bất kể nó ở database/cloud/xml/nosql... Có y như cái Repository của các a chưa? :look_down:

:confused:

Ái chà chà, Thế là anh phải xử lý lại generic của iqueryable, rồi migration của cái dbcontext đó à.

Rồi phải xử lý command build từ linq + execute command nữa chứ

Đây là ko chỉ là phát minh lại bánh xe mà anh phát minh lại cả cái xe rồi :beat_brick:
 
https://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework-core/

:misdoubt:

1644565113842.png


1644565087441.png
 
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. :canny:
Ko phải ko đáp ứng đc mà là tách ra cho đỡ cồng kềnh ấy mà
Orm chứa mapping và get set thôi.
Còn repo chứa query.
Chưa kể join diếc nhìu bảng các thứ ai đi để trong orm
lol.gif
lol.gif
, và cũng ko đc để trong service
 
Last edited:
:confused:

Ái chà chà, Thế là anh phải xử lý lại generic của iqueryable, rồi migration của cái dbcontext đó à.

Rồi phải xử lý command build từ linq + execute command nữa chứ

Đây là ko chỉ là phát minh lại bánh xe mà anh phát minh lại cả cái xe rồi :beat_brick:

Nó có khác gì chuyện anh custom Repository để support query, join, include, where giữa các Repositories với nhau ko? Một cái implementation đúng của Repository là phải xử lý được query giữa các repository với nhau.

Anh thấy vấn đề của anh chưa?
 
Nó có khác gì chuyện anh custom Repository để support query, join, include, where giữa các Repositories với nhau ko? Một cái implementation đúng của Repository là phải xử lý được query giữa các repository với nhau.

Anh thấy vấn đề của anh chưa?
Ơ kìa, repo có thể truy câp vào current dbcontext mà. Anh đang nghĩ là scope của nó chỉ ở trên entity đó thôi á. :beat_brick: thế thì repo bên anh ngu bỏ mẹ
 
Mình thì không dùng .NET như mấy thím nhưng theo ý kiến chủ quan của mình thì Repositories là hay nhưng không nhất thiết phải bắt buộc, cũng đã áp dụng cho 1 số trường hợp như đấu nối với API gửi mail (Mailgun, SES, Sentry...). Các phương thức liên quan thì khá giống nhau (như gửi mail, tracking hay nhận event). Tuy nhiên nội dung code để xử lý logic thì lại khác. Khi 1 trong các thằng trên bị lỗi thì sẽ phải binding lại cái interface để swicth qua thằng khác. Chứ code tích hợp theo chiều ngang mà if else thì toi.
 
Ơ kìa, repo có thể truy câp vào current dbcontext mà. Anh đang nghĩ là scope của nó chỉ ở trên entity đó thôi á. :beat_brick: thế thì repo bên anh ngu bỏ mẹ

Thế thì tôi dám chắc 90% cái layer service của anh dek có cái gì phức tạp trong đó vì đa số các query bị anh đẩy xuống repository hết rồi. Lúc này repository của anh chỉ là 1 cái như "Data Access service" để gọi dbContext cross nhiều entity thôi.

Anh nhìn lại cái logic của service layer trong dự án của a có phải đa phần chỉ là wrap thằng repo ko?

Nếu nó dek có gì thì dẹp thằng Repo rồi move lên service luôn ko tốt hơn sao?

Rồi chuyện anh quản lý transaction ở nhiều repo thế nào? Tầng nào chịu trách nhiệm commit/rollback transaction? Repo hay Service?
 
Thế thì tôi dám chắc 90% cái layer service của anh dek có cái gì phức tạp trong đó vì đa số các query bị anh đẩy xuống repository hết rồi. Lúc này repository của anh chỉ là 1 cái như "Data Access service" để gọi dbContext cross nhiều entity thôi.

Anh nhìn lại cái logic của service layer trong dự án của a có phải đa phần chỉ là wrap thằng repo ko?

Nếu nó dek có gì thì dẹp thằng Repo rồi move lên service luôn ko tốt hơn sao?

Rồi chuyện anh quản lý transaction ở nhiều repo thế nào? Tầng nào chịu trách nhiệm commit/rollback transaction? Repo hay Service?


Rồi chuyện anh quản lý transaction ở nhiều repo thế nào? Tầng nào chịu trách nhiệm commit/rollback transaction? Repo hay Service?

Đây rồi, lúc tôi nói Unit OF Work thì a cãi đi. Cái xử lý + quản lý nó chính là UOW đó anh ạ. Luận điểm chắc chắn cho cái repo pattern của bên anh cùi bắp, nên a bị sai hết các định nghĩa rồi
 
Rồi chuyện anh quản lý transaction ở nhiều repo thế nào? Tầng nào chịu trách nhiệm commit/rollback transaction? Repo hay Service?

Đây rồi, lúc tôi nói Unit OF Work thì a cãi đi. Cái xử lý + quản lý nó chính là UOW đó anh ạ. Luận điểm chắc chắn cho cái repo pattern của bên anh cùi bắp, nên a bị sai hết các định nghĩa rồi

Tôi hiểu mô hình của anh sẽ như này:
Controllers -> Services -> IUnitofWork (commit/rollback) -> IRepo1, IRepo2... -> dbContext

Cái anh chưa thông là thằng ORM nó đã implement UnitofWork, Repo cho anh rồi!
Controllers -> Services -> dbContext (commit/rollback) -> DbSet<Entity1>, DbSet<Entity2>
 
Last edited:
Tôi hiểu mô hình của anh sẽ như này:
Controllers -> Services -> IUnitofWork (commit/rollback) -> IRepo1, IRepo2... -> dbContext

Cái anh chưa thông là thằng ORM nó đã implement UnitofWork, Repo cho anh rồi!
Controllers -> Services -> dbContext (commit/rollback) -> DbSet<Entity1>, DbSet<Entity2>

https://aspnetboilerplate.com/Pages/Documents/Unit-Of-Work

Tôi thông cho anh nốt cái này, còn hiểu được bao nhiêu là do anh nhé. :beat_brick:
 
https://aspnetboilerplate.com/Pages/Documents/Unit-Of-Work

Tôi thông cho anh nốt cái này, còn hiểu được bao nhiêu là do anh nhé. :beat_brick:

Tôi hiểu cách của anh. Nếu dùng attribute thì chả giống như là dùng AOP để move cái việc quan lý transaction ra thành 1 chổ riêng thôi. Nó vẫn là làm chuyện quản lý transaction ở tầng service

Từ link trên:

Cách 1 dùng attribute
C#:
[UnitOfWork]
public void CreatePerson(CreatePersonInput input)
{
    var person = new Person { Name = input.Name, EmailAddress = input.EmailAddress };
    _personRepository.Insert(person);
    _statisticsRepository.IncrementPeopleCount();
}


Cách 2: gọi y như tôi bảo phía trên:

C#:
public class MyService
{
    private readonly IUnitOfWorkManager _unitOfWorkManager;
    private readonly IPersonRepository _personRepository;
    private readonly IStatisticsRepository _statisticsRepository;

    public MyService(IUnitOfWorkManager unitOfWorkManager, IPersonRepository personRepository, IStatisticsRepository statisticsRepository)
    {
        _unitOfWorkManager = unitOfWorkManager;
        _personRepository = personRepository;
        _statisticsRepository = statisticsRepository;
    }

    public void CreatePerson(CreatePersonInput input)
    {
        var person = new Person { Name = input.Name, EmailAddress = input.EmailAddress };

        using (var unitOfWork = _unitOfWorkManager.Begin())
        {
            _personRepository.Insert(person);
            _statisticsRepository.IncrementPeopleCount();

            unitOfWork.Complete();
        }
    }
}

Tôi nói thẳng cái link trên là TÀO LAO luôn.

Anh có thấy là thằng post bài này nó ko biết EF đã support chuyện đó rồi chưa? Mấy anh apply theo kiểu monkey ko não ấy.

Mục đích anh tạo lại Repository Pattern và UnitofWork là Useless!
 
Mới đi uống cafe về giờ vẫn thấy còn cãi nhau à :nosebleed:

Đã gọi là pattern thì có bao giờ đúng hay sai đâu, nó chỉ là cách tổ chức code, anh thích dùng pattern nào thì dùng.

Anh gom hết đống code vào controller xử lý cũng chạy được, anh tách nó ra controller service repository cũng chạy được. Tóm lại là chả có cái gì đúng hay sai cả, tùy từng team mà xài cách phù hợp thôi.
 
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ý do mà các a đưa ra thì thằng ORM đều làm tốt hoặc custom tốt.
 
riết rồi cái box gì toàn cãi nhau, sợ vãi ignore ông thớt r
tôi đọc lại cả cái unit test nữa, cũng hay phết. để thảo luận trà nước thôi, hay hơn đọc nga mỹ cbi fang nhau nhiều :D

bao giờ con ếch mở con mắt thứ 3 ra thì ae khóc thét. the frog có dự án ngon, tuyển cuoc_song về làm sa lương tháng 10k, tuần làm 4 ngày ở nhà, lên cty 1 ngày thì nhảy vội :D
 
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#.
 
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?
 
Back
Top