Pulling a view to compare against post data and add to db POST in Web API


New member
Sep 30, 2021
Programming Experience
This is a quick question about Core 5 web api with entity framework.
The API is attached to a SQL db that needs to do CRUD operations on it dependent on a Angular 11 client app.
In addition to the CRUD operations, which are all working provisionaly, I also have a view present on the same DB that is a list of users that have a uniqueidentifier that is not null,
this unique identifier needs to be added to the POST operation.
The Unique Identifier can be obtained by matching the incoming USerID that is MSAL profile against the View on Email.
Do I use repository pattern and Unit of Work? Or is their way to inject into Creation DTO.
Can't use Azure AD groups or any infrastructure.
Also need to Authorize the user to perform the action on the controller , dependent on the value of a field in the view.
Hope this makes sense, to be fair I'm a little short of time to do this, to try and fail at an approach, really need a concrete strategy that is going to work.
Thanks for reading.


Staff member
Apr 6, 2019
Chesapeake, VA
Programming Experience
Moving to Web Services sub-forum since it sounds like you are asking for advice on how to design your web service's API.

You don't really need to implement a Repository pattern since Entity Framework already provides that for you. As I recall, there have been some blog posts about it being an anti-pattern to wrap the Entity Framework calls within a Repository pattern.

As for using Unit of Work, it really depends on whether your CRUD operations span multiple tables or the tables that your entities are supposed to abstract away; or if the CRUD operations require you to set up transactions because you have to touch multiple tables. If not, then you don't really need the pattern physically, but it may help you (and those who read and maintain your code later) to be able to visualize the code flow or logic.

Authorization is normally based on the caller of a method/action. It's seems kind of unusual to base authorization depending on what the caller is currently viewing. It's like saying that Picard can order a self-destruct of the Enterprise only if he is in the holodeck. You may want to re-examine your API, or more likely, the entire use case for which you are implementing the API.
Top Bottom