C#•2y ago

EF Core & Repository pattern

Our app was initially built using MongoDB and we implemented a repository layer over it. We then migrated to postgres & EF Core and basically kept the repository layer in the initial migration phase. Now I understand its more of an anti-pattern & we are ready to move away from it, what is the "norm" alternative? Instead of having repositories build extension methods? Like this? (very basic example from a blog post)

public static class MyLinqExtension 
{
    public static IQueryable<int> MyOrder 
        (this IQueryable<int> queryable, bool ascending) 
    {
        return ascending
            ? queryable.OrderBy(num => num)
            : queryable.OrderByDescending(num => num); 
    }
}

public static class MyLinqExtension 
{
    public static IQueryable<int> MyOrder 
        (this IQueryable<int> queryable, bool ascending) 
    {
        return ascending
            ? queryable.OrderBy(num => num)
            : queryable.OrderByDescending(num => num); 
    }
}

Mostly referring to Patrick's post here https://discord.com/channels/143867839282020352/536023005164470303/550428647719174363 which started the discussion in our team. Biggest concern is wanting to re use queries in other services etc.

7 Replies

MODiX•2y ago

patrickk#0001

OK SO.......... When you're using Entity Framework, especially EFCore, there is no real need for a repository because EF already is a repository. While previous versions of EF were the same, it was incredibly hard to "mock" or test the use of Entity Framework in classes because it would end up making a real database call, which is undesirable in tests. People came up with the idea of coupling EF with the repository pattern to make testing easier. This has the """"bonus""" effect of abstracting EF. This is where your problems begin. Because repositories are written by you, you're effectively massively dumbing down EF. You cannot use any of its "powerful" APIs outside of the repository for specialized purposes and often developers will then limit themselves to the holy grail of shit that are generic repositories. EF already is a repository. You're writing a repository over a repository. Once you have that repository written, you end up needing to solve the problem of the db context scope - which we might refer to as a unit of work. EF implements a unit of work. EF has a unit of work that's more than capable of providing what you require; HOWEVER, once you abstract EF away under a repository you lose that as well, so suddenly you need to write your own unit of work mechanism, slowly rewriting aspects of EF that you could just be using directly to make both your and your app's life easier and better. Finally the immense layering and baggage that comes with the repository pattern just ends up impeding any time you could be spending doing something valuable, like getting your app to work. This isn't a rant against the repository pattern, this is a rant against using the repository pattern over EF, especially EF Core. Please don't hate me MODiX devs.

Quoted by

<@!468482252041355285> from #modix-development (click here)

React with ❌ to remove this embed.

mikernet•2y ago

Extension methods on the DbSets for adding custom behavior is what I do Not sure about the IQueryable<int> example you gave though That can easily be done with existing LINQ methods

zuf•2y ago

Was just a quick copy from a blog post to explain what I mean, but yeah moving to extension methods on the DbSets is what we are thinking, just wanted some confirmation. You use that for reading, updating & deleting data?

mikernet•2y ago

I stick to built in functionality for all that unless its something particularly complex

zuf•2y ago

Okay, so basically you have a read extension that returns the user for example, you make changes to the entity and then just call DbContext.SaveChanges...() in your service layer?

mikernet•2y ago

Yeah

zuf•2y ago

Okay cool! Thank you for your time. Will use that approach then as well

Gaming

Programming

EF Core & Repository pattern