C#•3y ago

❔ Data Layer communicating ultimately to API controller

Hello

I was wondering if someone has a best practice for this?

I want that my Data Access Layer (Repository using Entity framework) communicates to my API controller to tell it if :

1) If the item to update was not found with corresponding ID in DB
2) If the item to update can not be updated because some item in DB already uses its UNIQUE name
3) If the item has successfully been updated

Usually I return to my API the Item if success, or null if not found. But here, I must also communicate if item with unique name already exists, and the controller must know so that I can return valuable info to the API consumer.

Do you think that throwing Exception from the data access layer, bubbling it to my Business Layer, and finally catching it in my API Controller is a good idea?

I have doubts because some people say exceptions should really be exceptional, and I don't feel like these Database Update impossibilities are really exceptional ?

Is there another better way to do this ?

Any help will be very much appreciated !

artya•7/15/23, 6:05 AM

Why not return something like an UpdateResult?

Pobiega•7/15/23, 7:06 AM

Yep, the trick here is to use a better return type. If you JUST need the status, an enum like above will be fine.

Pobiega•7/15/23, 7:06 AM

If you want more, I suggest a proper result type.

Pobiega•7/15/23, 7:07 AM

Exceptions should be exceptional, and not used for controlflow or business logic.

FilomeonOP•7/15/23, 7:39 AM

Ok, very nice, an enum will do the trick, and a class if I need to pass more data.
So, exceptions are a bad idea for this, now i know

Thanks a lot!

linqisnice•7/15/23, 7:56 AM

@tarcacodein which situation would the item not be found? if you are passing item X to the client for users of your application to see and interact with it, if it's not there hwen they click it, that is indeed exceptional and potentially a big problem

linqisnice•7/15/23, 7:57 AM

In that case, you could just do Single or First when fetching the item

FilomeonOP•7/15/23, 8:11 AM

It is in case where someone from the client sends to my API a request to update an item but gives a non-valid id for this item. Then my api will send the update request to the DB, the DB won't find any entity corresponding, ultimately returning a BadRequest("Item not found") to the client

linqisnice•7/15/23, 8:11 AM

Gotcha, but how are they even seeing items to update? aren't they fetched from your DB as well?

FilomeonOP•7/15/23, 8:12 AM

Yes they are

i wanted to make a super robust api but yes, maybe its not necessary?

linqisnice•7/15/23, 8:12 AM

if these items are coming from your db along with the pk/identifier in the db, then there should be no way for them to not be there unless you are deleting them or something

linqisnice•7/15/23, 8:13 AM

so yes that is exceptional imo

FilomeonOP•7/15/23, 8:13 AM

ok so an exception would be useful in this case ?

FilomeonOP•7/15/23, 8:13 AM

Thank you !

linqisnice•7/15/23, 8:17 AM

you dont have to throw it explicitly, first/single will do it for you

linqisnice•7/15/23, 8:17 AM

first is a bit faster than single but it does mask potential duplicates, which single won't

FilomeonOP•7/15/23, 8:28 AM

First will be a good choice here because there can not be duplicates, my properties are UNIQUE in the DB

Accord•7/16/23, 8:29 AM

Was this issue resolved? If so, run

/close

/close

otherwise I will mark this as stale and this post will be archived until there is new activity.