C#•17mo ago

✅ EF Best way to do UPDATE on entity

Hello,
EF by default tracks entities. That means, if a property of an entity is modified,

SaveChanges()

SaveChanges()

SaveChanges()

SaveChanges() will do the update.

Now, I set new values for the properties in the business logic layer, and the repository layer is responsible for any DB operation.

My current method looks like this.... Is there a clearer approach or leave this as it is?

c#
public async Task UpdateEntityAsync()
{
    try
    {
        await _dbContext.SaveChangesAsync();
    }
    catch (Exception)
    {
        //
    }
}

c#
public async Task UpdateEntityAsync()
{
    try
    {
        await _dbContext.SaveChangesAsync();
    }
    catch (Exception)
    {
        //
    }
}

c#
public async Task UpdateEntityAsync()
{
    try
    {
        await _dbContext.SaveChangesAsync();
    }
    catch (Exception)
    {
        //
    }
}

c#
public async Task UpdateEntityAsync()
{
    try
    {
        await _dbContext.SaveChangesAsync();
    }
    catch (Exception)
    {
        //
    }
}

CCore Hello, EF by default tracks entities. That means, if a property of an entity is ...

Yawnder•8/22/24, 4:55 AM

Just don't add any kind of repositories on top of your DbContext. Just let your service deal with the DbContext directly.

CoreOP•8/22/24, 4:58 AM

Well, there is a quite large 100 row+ complex query for cursor pagination + filtering. And the app is built with N-tier architecture

Yawnder•8/22/24, 4:58 AM

What does that have to do with anything?

CCore Well, there is a quite large 100 row+ complex query for cursor pagination + filt...

TeBeCo•8/22/24, 5:25 AM

so it would be the exact same amount of data, but you'd be adding more complexe code, more code indirection and more place to insert bugs you mean ?

CoreOP•8/22/24, 5:27 AM

If the repository layer (the one wrapping the EF queries) is removed, then the code should go somewhere

TeBeCo•8/22/24, 5:28 AM

either an extension method doing just that or in your services

TeBeCo•8/22/24, 5:28 AM

because your exception handling is very probably specific to that specific code colocation

TeBeCo•8/22/24, 5:28 AM

you can't generally have a generic way to handle all error

TeBeCo•8/22/24, 5:29 AM

also EFCore will raise more than just random exception

TeBeCo•8/22/24, 5:29 AM

because with that you cannot differenciate a duplication violation versus "network broke"

Yawnder•8/22/24, 5:34 AM

With repositories on top of EFC's repository (yes, EF/EFC already implement the Unit of Work and the Repositories), you lose key abilities like projection and dynamic filtering, unless you add in tons and tons of pass-through that you have to add in, with all the boilerplate that goes with it.

YYawnder With repositories on top of EFC's repository (yes, EF/EFC already implement the ...

CoreOP•8/22/24, 5:40 AM

Yes, this is very true. Thanks for pointing it out

Yawnder•8/22/24, 5:41 AM

Just so you know, a LOT of people make this mistake.
I've done it too.

TTeBeCo also EFCore will raise more than just random exception

CoreOP•8/22/24, 5:42 AM

I have a middleware catching exceptions. Would it be reasonable for doing a similar solution for EF exceptions, so no try, catch blocks?

Yawnder•8/22/24, 5:42 AM

Where I'm working at now, there is a senior dev that has been using .Net for almost 20 years now, and they still want to use repositories to wrap EF

CoreOP•8/22/24, 5:44 AM

If not wrapping, should I put them in private methods inside the logic layer?

CCore I have a middleware catching exceptions. Would it be reasonable for doing a sim...

Yawnder•8/22/24, 5:44 AM

This logic should generally be implemented at the service/logic level, since it's at that point that you know how to handle what.
If you want, you can let some exceptions through, like the DbUpdateConcurrency exception, and have these handled by a middleware.

CCore If not wrapping, should I put them in private methods inside the logic layer?

Yawnder•8/22/24, 5:45 AM

I'm not certain of what specifically you're talking about, so it's hard to give an advice on that.

CoreOP•8/22/24, 5:53 AM

Thanks for clarifying this concept

CoreOP•8/22/24, 5:53 AM

It helped a lot

Yawnder•8/22/24, 5:54 AM

Great! Good luck! Gotta go to bed now

CoreOP•8/22/24, 6:00 AM

$close

CCore $close