0

Assume you have the following model with navigation properties for EF Core

public class Person 
{
     public Guid personId { get; set; }
     public Guid departmentId { get; set; }
     public string FirstName { get; set; } = null!;
     public string LastName { get; set; } = null!;
     public int  Age { get; set; }
     public double Salary { get; set; }
           
     public virtual Department Department { get; set; }
}

Now I would for example create the following DTO to send and receive data from a client app that contains the following

public class Person 
{
     public string personId { get; set; }
     public string departmentId { get; set; }
     public string FirstName { get; set; } = null!;
     public string LastName { get; set; } = null!;
     public string Age { get; set; }
     public string Salary { get; set; }
}

I would do it this way (i.e making all properties strings) for the following reasons:

  1. It would cause my application to throw an exception if one of the properties has a wrong type (i.e the client provided the personID as a string instead of Guid) and there is no way to catch this exception, even with an exception middleware (at least I haven't found a way to do that yet). I know of UseStatusCodePages to catch errors so maybe I can use it to catch error code 500(assuming that is what the application would throw) and return an appropriate response to the client?

  2. Following the first reason, not throwing an exception would allow me to validate the properties using Fluent Validation.

Is this a bad practice or anti-pattern? And if you have a solution to how to catch the exception I mentioned I would really appreciate it.

Guru Stron
  • 102,774
  • 10
  • 95
  • 132
user19187727
  • 169
  • 9
  • Those are reasons *against* all-strings. If someone posts a malformed `personId` they'll get an automatic 400 response with an [RFC-7807](https://www.rfc-editor.org/rfc/rfc7807.html) ProblemDetails body. The same would happen if any data annotation failed. If you configure Fluent validation properly, the same will happen with fluent validation failures. – Panagiotis Kanavos Aug 29 '22 at 14:16
  • Moreover, the types and annotations become part of the Swagger schema clients can use to generate correct requests. – Panagiotis Kanavos Aug 29 '22 at 14:19
  • Then you get a 400 with a ProblemDetails body, not an exception. FluentValidation should work the same way if you call `AddFluentValidation` after AddControllers [as this blog post shows](https://codewithmukesh.com/blog/fluent-validation-aspnet-core/). Why do you get a 500 in the first place? Post your action code and configuration please – Panagiotis Kanavos Aug 29 '22 at 14:32
  • Did you forget to call `AddFluentValidation` perhaps? Or specify which properties are required, resulting in null properties instead of validation errors? – Panagiotis Kanavos Aug 29 '22 at 14:33
  • @PanagiotisKanavos this question is a total mess. You are 100% correct. Never thought about it that way. Thank you – user19187727 Aug 29 '22 at 14:36

0 Answers0