How is Modelstate.IsValid triggered?
Hello!
I am reading this tutorial on how DTO's can be implemented with API's: https://dev.to/moe23/net-6-automapper-data-transfer-objects-dtos-49e
The process in this tutorial seems normal and you can easily follow along.
There are only 2 things I have my questions about:
1. The Driver class in this tutorial has no DataAnnotations (see first codeblock). How come the Modelstate.IsValid can be triggered in codeblock 2?
2. How does Modelstate.IsValid get triggered when a Dto is passed but it gets mapped to an entity?
DEV Community
.NET 6 - AutoMapper & Data Transfer Objects (DTOs) 🗺
Intro In this article we will be exploring AutoMapper and Data Transfer Objects (DTOs) in...
39 Replies
If it can't bind json to that object. Like if it can't parse a string as a datetime. Or if the json is invalid in some way too, I think. Like if you pass
tru instead of true.Would not the _mapper function then crash?
No the parameter will have the defaults for those properties then
But that cab only happen if you turn off the filter that shortcircuits this in MVC
generally, it would return a response automatically at that point
Or maybe it will just be null? not sure
the mapper has nothing to do with ModelState
I have a little hard time to understand this.
thats correct
well just try passing some garbage json with the default mvc settings
and see what error you get
it won't even get to your code
oh like that.
But it will ignore extra fields, I'm pretty sure
and if you don't provide a value for a property, it will initialize it to null
if we check the Driver model for example in the code above. Lets say the driver number should be between 1 and 5 and the DTO contains 0?
then it should fail
no it won't handle that automatically
unless you do data annotations
and enable them, I think they aren't on by default
yes data annotations should be added. But you should not add data annotations on DTO's
Well then you won't be using MVC's system for validation
which isn't good in the first place, to be fair
data annotations are pretty primitive
Since the DTO comes in at the controller. you would 'normally' validate the object that comes in.
well one thing for certain
i do say that adding basic validation, like required or min/max length would be OK.
mapping typically never does any validation
A DTO can be invalid.
it just maps
One thing I learned when doing backbends for more than a year is that there's no great solution for anything in these frameworks. There's always a flaw in any tech you're going to use
Using controllers means a lot of code duolication
oh yeah thats for sure.
I am currently at my first ever job and making choices is the hardest part of it 😉
Using mediator is code duplication + boilerplate + indirectness
Using validation in MVC means no async validation
Cant i do the following?
1. Add basic validation like required,min/max length to the DTO
2. map the DTO to the entity
3. Perform more advanced validation to the Entity
4. By errors, return an error and if correct perform a save to the database
FluentValidation doesn't have a good foundation and is really hard to extend
I think you should only check for nulls and for that enum members match for dtos
Otherwise you're going to duplicate logic
that enum one was just an example, but i get that it might belong to the DTO
Yes, it doesn't validate enum members automatically, yiu heard that right
If you pass it a 5 and theres no 5 in the enum, it won't comlain
You don't have to map it to an entity necessarily either
It's easier that way, sure
for crud
but for stuff that isn't crud, generating sql is often just easier
One great thing about EF Core is that it keeps around the db model
With table names and mappings from properties to columns
That thing's great for query generation
Well, I need to use DTO/Entitities since my Entity contains properties i dont want to expose to a client. A DTO is excellent in this case.
No you should use dtos always for sure
That's not even an argument worth having
Okay good haha 😄
My advice is that db entities must correspond to the db tables as close as possible
Don't be tempted to add ignored fields that some service finds useful
If you have to do that, it means you need another domain model
When Mr. chatgpt generates an example I see it do the following:
1. The DTO has basic validation
2. The entity constructor has complex validation
3. An exception gets thrown when the complex validation fails.
Yes i have that, definitely dont worry about that part :). I am just struggling with the validation part between the DTO and Entity.
Nah that's dumb imo
It makes sense conceptually to make sure your objects are always valid and stuff
the domain objects should be valid when theyre created or when theyre ready to be stored in a database.
But you don't want that to actually happen, or have to happen, automatically
Then also you're forced to do excaptions
And can't collect errors easily
just don't
validate separately
when required
When storing stuff in the DB, you want the data to be correct (i mean thats a fact)
during the process from receiving the data to storing it, the data should be validated.
It's not possible to validate objects individually in the context of a database
Especially in the constructor
You're going to have to make other queries to properly validate stuff
likely
And you can't "just" forget that. It's like forgetting to open a transaction. Or create a query string and forget to run it.
imo you need to be able to control that manually
Also, basic entity validation can already be achieved from your database model
I have never seen anyone do this for some reason, but that's how you should ultimately do it
I use mongo so there is no validation :kekw:
No there is
You do specify max length and stuff for fields when you configure the db with ef core
You can validate according to that info
Which is ultimately the only correct way
You don't have to duplicate any configuration
if EF Core is the source of truth, the validation should reference tgat
Mongo has no integration with EF.
I've heard it does now
not sure how good it is
yeah that package is still in its baby phase. cant use that in production
I'd use it even if it doesn't support queries
just for the sake of the model