Does it make sense to encapsulate exception handling by moving the code from the controller to an entity method?

Question

ASP.NET

Good afternoon!
Tell me, what do you think, how best to implement a check for the presence of some entity when changing

public ActionResult SomeController(SomeModel model)
{
  
  var entityDT = m_repository.Get(model);
  
  if (entityDT == null)
  {
    HttpNotFound();
  }
  else
  {
    Automapper.Map<SomeModel,SomeEntity>(model, entityDT);
    m_repository.Save(entityDT);
    
    return View();
  }
  
}

or

public ActionResult SomeController(SomeModel model)
{
  
  var entityDT = m_repository.GetOrNotFound(model);
  
  Automapper.Map<SomeModel,SomeEntity>(model, entityDT);
  m_repository.Save(entityDT);
  
  return View();	
}

or your choice

Answer 1

1) Controller - connects the UI and the logic, but this is not the logic itself, the maximum here is the preparation of the model for further transfer. GRASP - Controller.
2) Logic for receiving, mapping, etc. transfer to service. SomeModelService for example.
3) Repository is just a collection, there are no not_founds there.
4) This scenario, as I understand it, updates the existing entity. This means that we should probably add a check for competitive access, optimistic, because. this is web. Those. let SomeModel have a version value, a date, or an int, or whatever is convenient for you. And handle all possible situations not in the controller, but in the service. Because UI may be added another.
5) Instead of specific repositories and services, use interfaces. SOLID, letter D. This will allow you to easily test your application and develop modules without having to wait for all the other modules you are using.
But if the application is simple, or educational, then you can just forget about all this, because. the overhead is large, and sawing as convenient. In this case, the difference between 1 and 2 is not much, but the 1st is cleaner.
It is good to peep examples of any GetOrXXX at C# LINQ. FirstOrDefault etc.