Is it better to use entity property vs assignments in http post controller? - entity-framework-core

Question

So say we have an aspnet core2 controller that's returning HttpPost object from another app.
Im using Entity framework core and both ways work but I'm just curious into best practices and performance to know what to use?
[HttpPost]
public Message Post([FromBody] Message message)
{
// my old code
// var msg = new Message { Owner = message.Owner, Text = message.Text };
//db.Messages.AddAsync(msg)
var msgEntity = db.Messages.Add(message).Entity;
db.Messages.AddAsync(message);
db.SaveChangesAsync();
return message;
}
Something strange happens when I use Entity as well it changed the auto incremented Id parameter {Id:1002} when before I added it the next consecutive Id was suppose to be {Id:11}

Answer 1

You should never save anything from a request directly. There's your best practice. The previous code is superior for the sole reason that you're explicitly choosing what posted values are actually persisted, rather than just blindly saving anything a user decides to send directly to your database.
The even better approach is to actually use a view model to accept user input. For example:
public class MessageViewModel
{
public int OwnerId { get; set; }
[Required]
public string Text { get; set; }
}
Then, you accept this as a param, instead, and map it onto your entity:
public async Task<IActionResult> Post([FromBody]MessageViewModel model)
{
if (ModelState.IsValid)
{
var message = new Message
{
Owner = db.Users.Find(model.OwnerId),
Text = model.Text
};
db.Messages.Add(message);
await db.SaveChangesAsync();
return Ok(message);
}
return BadRequest(ModelState);
}
There's a number of important changes I made in the above code:
Added a conditional to check if ModelState.IsValid is true before proceeding with the save. As you have it now, you're just blindly attempting to save whatever gets passed in, even if doing so will end up raising a database exception because required values are missing and such.
With this conditional, you now need to handle the scenario where there's an issue. More likely than not, you'll want to return some sort of error object, to help the client fix issues. It's common to actually just return ModelState, which will serialize its list of validation errors, but you might want to do other things as well.
Since this now require potentially returning two different object types, the action signature has been changed to return IActionResult. It's usually better to just use this return type all the time. It's a catch-all, basically, whereas a specific return like Message can easily outgrow its usefulness, requiring you to just go ahead and change it later. You should really only return specific types when there's absolutely no chance of failure of any sort, i.e. the response will always be 200 OK. However, scenarios where that's the case are few and far between.
The view model just accepts the owner's id, instead of a full (presumably ApplicationUser) object. The same problem with accepting a Message and saving it directly exists here too. A malicious user could fudge with the Owner object properties, allowing them to potentially change all sorts of things that shouldn't be changed. In general, you should always set out to allow the user to manipulate as little data as possible. Anything you expose, should be done on purpose, fully understanding the implications. Since, we're now only accepting an id, we then need to look up the user with that id, to set the Owner property on the entity. If you happened to have an explicit foreign key property, such as OwnerId on Message, you could just set that directly.
Changed AddAsync to just Add. According to the documentation, you should almost never use AddAsync. It only exists for a very specific purpose that you're unlikely to ever encounter. It is recommend to always use Add, unless you have a good reason otherwise.
Added await to the SaveChangesAsync call. Always await asynchronous operations unless the completion of the operation as no bearing on anything. Here that's definitely not the case. SaveChangesAsync can raise exceptions, exceptions that your application will need to handle. Not awaiting it, basically just swallows these and lets the code happily continue as if there was no issue. Although that may sound like a positive, it is definitely not. There's also other issues that can be caused by not awaiting, such as the context may end up getting disposed before the call finishes.
Since we're now awaiting SaveChangesAsync, async must be added to the method signature, and you must return a Task<IActionResult>.