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

[mavbeez]

Hi,
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.
Regards

 

[Skydiver]

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.

 

[jmcilhinney]

You can basically think of the EF DbContext as the unit of work and each DbSet as a repository.

 

[Zomab]

Yes, your question makes sense.
Based on your requirements, here's a suggested approach:
Use the repository pattern to abstract away the data access logic from your controller.
Create a repository for the User entity, which will handle all CRUD operations related to users.
Create a repository for the UserView, which will handle queries to the view.
Use the Unit of Work pattern to ensure atomicity and consistency of data changes.
Use Dependency Injection to inject the repositories into the controller.
Add an additional parameter to the POST method of your controller to accept the user's unique identifier.
In the controller, retrieve the unique identifier from the UserView repository by matching the incoming UserID against the view on Email.
Add the unique identifier to the creation DTO before passing it to the User repository's Create method.
Add authorization logic to the controller action using the Authorize attribute and a custom authorization policy that checks the value of the field in the view.
Here's an example of how the controller action might look:

[HttpPost]
[Authorize(Policy = "SomeCustomPolicy")]
public async Task<IActionResult> Create([FromBody] CreateUserDto dto, string userId)
{
   var uniqueIdentifier = await _userViewRepository.GetUniqueIdentifierByEmail(dto.Email);
   dto.UniqueIdentifier = uniqueIdentifier;
   var user = _userRepository.Create(dto);
   await _unitOfWork.SaveChangesAsync();
   return CreatedAtAction(nameof(GetById), new { id = user.Id }, user);
}

Of course, this is just one way to approach the problem, and there are many variations and nuances to consider depending on your specific requirements and architecture. But hopefully, this provides you with a concrete strategy to move forward with. If I couldn't answer your question, then it's worth getting in touch with software development experts who can advise you *removed spammy link*

 

[Skydiver]

@Zomab : I removed the spammy link to your services. There is an appropriate subforum if you want to advertise your services.

As it is now, I'm kind of dubious of your services. By using Entity Framework, the repository and unit of work patterns are already built into EF. You are just adding another layer on top of it and not really providing any value.

 

[cjard]

Floating two year old threads that are probably well solved by now is also "not really providing any value"