47 Replies
data being inputed into the db.. indexes, required, lenght that sort of stuff@Pobiega
db protecting itself from bad stuff reasoning 🙂
ex. u could validate if a required prop exists in the dto and let the db handle rest. or validate in the controller (some do service) and make it so nothing goes down
ive seen different opinions so i ask here too
you certainly shouldnt need that, unless you are inserting into DB from outside EF
i mean this is a validation
using ef to configure a model
that is not a validation
thats an entity configuration
yes but u can configure it that it has max 40
if u try to enter 41 the db is gonna say no
its a validation
its not thou
so the question is maybe what do we leave to the db and what take outside
thats a more interesting question
basically what i was asking but put in 1 line 😄
your database schema (thats what configuring your models does) prevents bad data, but only by causing DbUpdateExceptions, which is often unideal
so do that for shit that "this shouldnt be possible"
i thought about it lil while i was outside this is the thought process that i had
ok am i building the client and there isnt going to be any other client. so 1 of each (db, api, client)
am i going to have multiple clients 1 api
multiple api using the same db
might come down to that where does it get placed
even multiple db single api
if im building my own that im going to use, or other ppl gonna connect to it.. i protect my stuff dont care what others do 🤔
this is a really great idea, and I've done it once
there's no library for this, you have to do something custom
entity framework has annotations and fluent api to do it
on the db level
not on the api level
db level u go to your dbms and do it 😄
code first so efcore
this is bad
thats not the problem, there are complex validations which are pretty much business rules
your frontend needs to have this info
you want to propagate this
all the way to the frontend
so you don't duplicate your configuration in two places
the max length should end up in the swagger schema
ex. we have 50 in stock tenant 1 can order 60 tenant 2 cant order above max
thats a business rule that needs to be validated
it doesn't check it btw, it just truncates
at least most dbs just truncate
🤔
I mean, this does need specific code
yy
but if it's something like the string length
you want it to only be configured for the db
and still reach the api schema
y i figured using ef core to setup the db fully and fluidvalidations to do business
so you either pull it from the ef core db model
or duplicate it on the dtos
y thought of duplicate
that's what I managed to pull from the db model once
looking at the db as a separate entity that any api can access
the db wont allow bs to be entered
and the api needs to know whats allowed
the api dude can duplicate the validations so the request doesnt waste time going to db the moment it finds a mistake throws an exception or sends a msg
thinking out loud rn
junior still 🙂
the idea is to:
1. have a mapping between db entity and dto properties to be able to know which column to pull the max length from (I just did it by name, ideally a mapper library should provide this metadata, but none of them do);
2. use some undocumented MVC thing to add a validation handler to those properties for that type;
3. make a schema filter that knows how to interpret this MVC validation handler as MaxLength;
4. inject db model into the MVC thing that sets up validation to do the property mapping and pull the max length information.
that's how I did it at least
with fluent validation it's going to be more involved, because you can't transparently inject dependencies into them
it is kind of crazy that there's no library for this
seems to me like a must have idea
@Antondont know if i misunderstood
u can DI anything into the Validators constructor
I know
ah ok ok
but you can't say "all validators now have this"
you have to do that manually for each one
understood
an issue i see is i gotta write it into every single endpoint
read something about filters need to research more, says not built in
dont rly want to keep adding dependencies on libraries
the thing I did applies globally
but it uses the data annotation validation system
from MVC
just piggybacks off of it
reading this rn
you can do this, but usually you'd often want to do it at a certain point you control
or have other context around before you do it
I actually found it helpful to do the more complex validation manually, with a custom error context that I can push errors to
problem is currenty the project im on i joined this month the others working on it couple months
because then I can interleave validation with pulling context from the db
i got thrown the validation bone with no info 😄
and you do need info from the db to validate stuff properly
i got no info on requirements/business rules
so im going blind rn just researching
talking more generaly bec of it without examples figuring out where stuff would go
in my experience, there's two sorts of validation
one is trivial
like max length
min max
enum parses or not
must not be null
these should be automatic
and then the other kind
where you want to validate business rules (like the thing you did with the length based on other stuff in the db), ownership of entities and limit certain things based on permissions
imo these should be done manually, when it's the best time for these
when all the context is around, and you're about to do the changes
understand so controller if controller got all to pass, service if using that architecture where controller is smol, aggregate 🤔
i get the dto and on that place in my architecture i have all the stuff i need from the background at the highest point 🤔
may be mapped already
I have no idea what you just said