I understand the limitations of data annotations, but I really liked the beautiful simplicity of it. As soon as your started delving into Fluent Validation the code suddenly drowned in boilerplate. Thank you so much though, I will be using data annotation validation going forward!
Agreed. For the simple type of validations he used in the video, FluentValidation is overkill. But once your validation logic because more complex, I can see the sense in going down this route.
I you don't need to do anything custom or complex then sure, it's good enough. The moment you start implementing more custom logic that requires injection of DI registered service, DataAnnotations fall apart.
@@nickchapsas I also like generally that the fluent approach decouples your business data model from the validation rules. Maybe not a big deal for a simple option type, but a good way to keep the SoC pattern consistent with other parts of the code where AOP on business objects falls apart.
Data annotation puts the validation right where it needs to be, right where everyone knows where to find it. Baffling why anyone would do something different.
I had started using it as it is quite easy to make a typo in your configuration. And more generally, I have found that self-checking code is just an awesome way to guard your solution any crazy spanner that your QA tester might throw at it. ;)
❤ it. Thank you Nick. Now I'm battling with build time settings and secrets and how to validate those. Further down the rabbit hole we go.
ปีที่แล้ว +16
I think it would also be interesting to see how to have a similar effect when options change. For example if you have settings within an Azure Vault and you would like to validate it as soon as it changes? Clearly this is no longer possible on application startup as application is already running, however it would be interesting to react immediately (if even possible?) and do something (log it or send email etc). It would be nice to see an additional video for solving such a problem :)
The code in the video will work fine you just need to replace the IOptions to IOptionsMonitor. Then every time you get the value, validation will kick in
ปีที่แล้ว +1
@@nickchapsas Does it also work for the first time (on startup)? Or do I have to do both? Where does the validation exception end up in?
@ The rule is that the exception is called when you try to resolve .Value from one of the IOptions wrappers. ValidateOnStartup() just calls an additional validation before .Value is first resolved.
Very interesting. I always learn a lot from watching your videos, although I usually have to watch them a few times as there is so much information in such a short space of time. I would love to know how this technique could be implemented when using the named IOptions pattern.
I particularly like putting both the configuration and validation of options in their own class. Microsoft did a good job when they designed the options library/pattern for .NET.
Wish an example would have been shown of using it with asynchrous code, like validating that an API key is valid as he had mentioned. Also would the validation logic be re-called if the settings are reloaded with the other option patterns (IOptionsMonitor I believe)?
This works if using the options in endpoints but it doesn't work if the options are needed during startup. Looks like ValidateOnStart() happens after ConfigureServices() and potentially after Configure(). Is there a way to validate earlier in the initialisation?
I love the idea! But my attempt at implementation has failed due to Scoped services that cannot be resolved from root provider. I'm trying to figure out a way to get around this when not being done within a minimal api like in your example. Any ideas?
Like the approach using FluentValidation over attributes personally. Options Pattern is really powerful, if a bit dense for something so important (and at the same time so un-exciting) to a project setup. I have tended to follow a similar approach with a validator (today explicit, maybe next time ill look at using FV), but not using the OnStartup bit as it is out of my control. Instead I cause validation to occur prior to the host Run so that I can log individual events for bad configuration bits and not just get the exception/stack trace output. Combine all that with using postconfigure for some options to smart-default or otherwise derive values and its a bunch for work for sure - but work that leads to a polished end result.
To bring OnStartup into your control you should configure liveness and readiness probes and check for ready state in your CD pipeline. Then deployment will fail if an application couldn't start and you will see a deployment error in your build server (and probably an alery in a chat, email, etc)
I'm doing this but it's a bit different. My AppSettings class as a Validate() function and I have an IStartupFilter which runs that function. In the end provides the same functionality i.e. throw a list of errors for any invalid settings on startup.
Any idea how to address the issue that when you inject an IOptions, if you haven't configured it, you get a default instance with all properties with their default value. Even if your setting object has required properties. For example, you end up with a null string that wasn't nullable and required.
I get stuck on terminology of options, as it's not an option they are settings within configuration. A section has configuration settings ...any reason why they called it options? On top of that is the default providers after configuration is instantiated. I think there are 7 default providers. I always clear then, and add back the provider I need
@@nickchapsas Ah ok, I feared I need to ask an AI to extract the code from the video ;-) Which Patreon, is it available with the TH-cam membership for your channel?
Hey Nick , can you make a video on how to write an exception middleware such that if any exception happens it should add it to output object and returns to the place where exception was thrown and continues execution
Hey Nick ! :) For thanks sharing this technique, i use to manage all my checks with DataAnnotations but i can understand that sometimes FluentValidation could be better for more complex case ^^ Juste have one questions on it, would you're technique also for "hot reload settings" case ? 🤔
I hate that to bind options i have to pass the config object. I wanted a way to do it using the registerd IConfiguration so i had to create me own extension methods to do that. imo that should be out of the box, idk why you wouldn't want your IConfiguration in your Iservicecollection so that you can inject it as needed and define more services (such as options) that are based on that.
They are dynamically loaded on startup. You can do the configuration in C# already the whole point is that JSON is a structured declarative markup syntax that makes specifying configuration easier. Any imperative logic you then use on top of that configuration is obviously done in C# already. You could do the whole lot in C# but its not going to be nicer which is why people dont do it.
Why not simply create an extension method that supports: var configSection = configuration.GetSection("key"); services.Configure(configSection); var settings= new T(); configSection.Bind(settings); settings.Validate(); Where T is of type IValidate and contains a Validate method.
@@nickchapsas Is there a way to keep the Fluent validation in the same class file as the options object so they stay coupled in the editor? Hiding the validation in another file breaks visual continuity.
Even validation at start time is too late IMHO. Validation should be done in the text editor while the user types in the values. Also there should be the IntelliSense suggestions and tooltips when hovering your mouse on top of the parameter names. This is achievable with schemas. I've been using XML schemas (xsd.exe) for my settings for more than a decade now. There was just no other alternative for the functionality I've described. But now JSON schema seems to be catching up with XSD, so the setting validation/documentation should also start using the schema and provide the validation/IntelliSense at edit time. But while we are not there yet this video is very helpful, thank you!
Most modern systems don’t store settings in a file but rather a server and load it on startup. Validating on compilation is both impractical and a security issue because it assumes you have secrets in your settings
I see you put your source code behind a paywall, which is fine. However, I can't in good conscience endorse Patreon usage to do so considering their immoral business practices. Also, would love to watch your videos on Rumble.
Honestly... Both design are horrible. An object should not exist in an invalid state. You can create simpler types that have the proper types (LogLevel enum, a type representing an int range or just using an unsigned int)... And handle reading the options as a deserialization problem. Goal is to remove boilerplate and have explict types.
One of the worst decisions I made was using Fluent validations instead of Data Annotation in a project. Strongly recommend not using them, just creates unnecessary boilerplate that leads to people not using simple validations because it requires too much. code and the validation is separate from your domain so it's much harder to figure out required rules. Not to mention that any sort of generation (OpenAI) is not native and requires extra setup.
@@nickchapsas The question their is should you have that in your validation logic. For example, if you use CQRS that additional logic is related to your business rules, and you can use things like pipelines in mediator to separate it. But even that leads to double query problems like with exists validation on updates so there is a good case to be made you should keep it in your commands. To me validation is transferable between systems you should be able to do it on the frontend and the backend the same way and services mean you can't do it.
It doesn’t matter if you use CQRS or any other form of separation of concerns. Settings validation is infrastructure related not business logic related.
@@nickchapsas Yes but that is only true for validation rules that don't require you use services can you give me an example of a service you would need that isn't related to requirements coming from the concrete requirements of the project you are working on?
@@FilipCordas I think you both have a point. Nick is talking about the specific case of appsettings, you're talking about the concept in general and I think (if what I said is correct) that you are both correct.
I understand the limitations of data annotations, but I really liked the beautiful simplicity of it. As soon as your started delving into Fluent Validation the code suddenly drowned in boilerplate. Thank you so much though, I will be using data annotation validation going forward!
Agreed. For the simple type of validations he used in the video, FluentValidation is overkill. But once your validation logic because more complex, I can see the sense in going down this route.
I you don't need to do anything custom or complex then sure, it's good enough. The moment you start implementing more custom logic that requires injection of DI registered service, DataAnnotations fall apart.
@@nickchapsas I also like generally that the fluent approach decouples your business data model from the validation rules. Maybe not a big deal for a simple option type, but a good way to keep the SoC pattern consistent with other parts of the code where AOP on business objects falls apart.
And it is still possible to implement logic in class derived from ValidationAttribute, which one perfectly works with DataAnnotationValidation.
Data annotation puts the validation right where it needs to be, right where everyone knows where to find it. Baffling why anyone would do something different.
I had started using it as it is quite easy to make a typo in your configuration. And more generally, I have found that self-checking code is just an awesome way to guard your solution any crazy spanner that your QA tester might throw at it. ;)
❤ it. Thank you Nick. Now I'm battling with build time settings and secrets and how to validate those. Further down the rabbit hole we go.
I think it would also be interesting to see how to have a similar effect when options change. For example if you have settings within an Azure Vault and you would like to validate it as soon as it changes? Clearly this is no longer possible on application startup as application is already running, however it would be interesting to react immediately (if even possible?) and do something (log it or send email etc). It would be nice to see an additional video for solving such a problem :)
The code in the video will work fine you just need to replace the IOptions to IOptionsMonitor. Then every time you get the value, validation will kick in
@@nickchapsas Does it also work for the first time (on startup)? Or do I have to do both? Where does the validation exception end up in?
@ The rule is that the exception is called when you try to resolve .Value from one of the IOptions wrappers. ValidateOnStartup() just calls an additional validation before .Value is first resolved.
Another rule is not to believe people on the Internet and to just test it yourself ;)
i will incorporate this into my current project, this could save me headaches later
Very interesting. I always learn a lot from watching your videos, although I usually have to watch them a few times as there is so much information in such a short space of time.
I would love to know how this technique could be implemented when using the named IOptions pattern.
I particularly like putting both the configuration and validation of options in their own class. Microsoft did a good job when they designed the options library/pattern for .NET.
Hats off Nick Chapsas!
How can this be implemented for options that need to be used to register other services? Is this validation performed when the services are built?
I love this approach. Thanks for sharing.
Wish an example would have been shown of using it with asynchrous code, like validating that an API key is valid as he had mentioned.
Also would the validation logic be re-called if the settings are reloaded with the other option patterns (IOptionsMonitor I believe)?
You are the best, even better than chat gpt
Love your videos. Never stop making them ))
This works if using the options in endpoints but it doesn't work if the options are needed during startup. Looks like ValidateOnStart() happens after ConfigureServices() and potentially after Configure(). Is there a way to validate earlier in the initialisation?
I love the idea! But my attempt at implementation has failed due to Scoped services that cannot be resolved from root provider. I'm trying to figure out a way to get around this when not being done within a minimal api like in your example. Any ideas?
Why do you use AddOptions and Bind methods? There is an overload of Configure method which accepts IConfiguration
Like the approach using FluentValidation over attributes personally. Options Pattern is really powerful, if a bit dense for something so important (and at the same time so un-exciting) to a project setup.
I have tended to follow a similar approach with a validator (today explicit, maybe next time ill look at using FV), but not using the OnStartup bit as it is out of my control. Instead I cause validation to occur prior to the host Run so that I can log individual events for bad configuration bits and not just get the exception/stack trace output. Combine all that with using postconfigure for some options to smart-default or otherwise derive values and its a bunch for work for sure - but work that leads to a polished end result.
To bring OnStartup into your control you should configure liveness and readiness probes and check for ready state in your CD pipeline. Then deployment will fail if an application couldn't start and you will see a deployment error in your build server (and probably an alery in a chat, email, etc)
I'm doing this but it's a bit different. My AppSettings class as a Validate() function and I have an IStartupFilter which runs that function. In the end provides the same functionality i.e. throw a list of errors for any invalid settings on startup.
This is very very good! Thanks Nick
Right on lunchtime 👌
I always wanted to make a code generator to auto create json schema for an option class so you get validation and auto complete.
Any idea how to address the issue that when you inject an IOptions, if you haven't configured it, you get a default instance with all properties with their default value. Even if your setting object has required properties. For example, you end up with a null string that wasn't nullable and required.
Would be neat if there were an additional fluent validation nuget package for this
But what if a string is entered into the Retries field instead of a number? How can we check for this case, since the error will occur during binding?
This looks like it would mix well with IValidatableObject does that happen automatically?
What would be the solution do turn this off if it is on "developer machine" ?
This cannot be done in an Azure Function App since it doesn’t use the Hosting package. Any workaround?
I get stuck on terminology of options, as it's not an option they are settings within configuration. A section has configuration settings ...any reason why they called it options?
On top of that is the default providers after configuration is instantiated. I think there are 7 default providers. I always clear then, and add back the provider I need
I don’t know why they went with options either. I clashes with the appsettings name too. Always annoyed me
Very nice..Lot of good things learning from you..
Fantasic, is there a place where I can find the code you showed us in this video?
Yea, my Patreon
@@nickchapsas Ah ok, I feared I need to ask an AI to extract the code from the video ;-)
Which Patreon, is it available with the TH-cam membership for your channel?
Still waiting for ConfigureAwait vid
Awesome content as usual!
Hey Nick , can you make a video on how to write an exception middleware such that if any exception happens it should add it to output object and returns to the place where exception was thrown and continues execution
This is going over my head. It tried but didn't understand why it is used.
Hey Nick ! :)
For thanks sharing this technique, i use to manage all my checks with DataAnnotations but i can understand that sometimes FluentValidation could be better for more complex case ^^
Juste have one questions on it, would you're technique also for "hot reload settings" case ? 🤔
I hate that to bind options i have to pass the config object. I wanted a way to do it using the registerd IConfiguration so i had to create me own extension methods to do that. imo that should be out of the box, idk why you wouldn't want your IConfiguration in your Iservicecollection so that you can inject it as needed and define more services (such as options) that are based on that.
Also would not it be nice to have appsettings in C# and load them dynamically on startup? Would that be possible ?
They are dynamically loaded on startup. You can do the configuration in C# already the whole point is that JSON is a structured declarative markup syntax that makes specifying configuration easier.
Any imperative logic you then use on top of that configuration is obviously done in C# already. You could do the whole lot in C# but its not going to be nicer which is why people dont do it.
How to add data annotation for a string that take http/https endpoint as a setting , to validate using ValidateDataAnnotations()
You would have that exception on startup if you registered the setting class as a singleton
Awesome!
Nice and clear way to validate settings 👌. Thanks Man
Thanks 👍
Very cool!
Ungh... Back in my days, developers copied code only from verified sources, such as StackOverflow. Never from the official framework... ☹
Sadly, it doesn't work for non-host apps like Azure Function or Aws Lambda.
I was just thinking does this work in functions. Thanks for the info 👍
Just discovered this myself trying this in maui and console types
Hi Nick!
Small heads up; theres a typo in the description
“settions” presumably in stead of “settings”
Cheers
Why not simply create an extension method that supports:
var configSection = configuration.GetSection("key");
services.Configure(configSection);
var settings= new T();
configSection.Bind(settings);
settings.Validate();
Where T is of type IValidate and contains a Validate method.
It looks like fluent validation is still the best approach in .NET 8.
Why not put the validation in the init methods themselves and throw exceptions?
Because it will make the options objects incredibly bloated. If that approach works for you then that’s fine, but I wouldn’t go down that path
@@nickchapsas Is there a way to keep the Fluent validation in the same class file as the options object so they stay coupled in the editor? Hiding the validation in another file breaks visual continuity.
@@IMarvinTPAyou can nest you Validator class inside your options class
Even validation at start time is too late IMHO. Validation should be done in the text editor while the user types in the values. Also there should be the IntelliSense suggestions and tooltips when hovering your mouse on top of the parameter names. This is achievable with schemas. I've been using XML schemas (xsd.exe) for my settings for more than a decade now. There was just no other alternative for the functionality I've described. But now JSON schema seems to be catching up with XSD, so the setting validation/documentation should also start using the schema and provide the validation/IntelliSense at edit time. But while we are not there yet this video is very helpful, thank you!
Most modern systems don’t store settings in a file but rather a server and load it on startup. Validating on compilation is both impractical and a security issue because it assumes you have secrets in your settings
I see you put your source code behind a paywall, which is fine. However, I can't in good conscience endorse Patreon usage to do so considering their immoral business practices. Also, would love to watch your videos on Rumble.
Honestly... Both design are horrible. An object should not exist in an invalid state. You can create simpler types that have the proper types (LogLevel enum, a type representing an int range or just using an unsigned int)... And handle reading the options as a deserialization problem. Goal is to remove boilerplate and have explict types.
ValueObjects for option types surely will remove all the boilerplate, but they are boilerplate in themselves. Terrible design
@@nickchapsas But they encapsulate their own boilerplates... Which I find merely terrible rather than horrible.
MORE classes!!! It’s the OOP way 😂
Seriously, creating value types for every setting in every section sounds horrible
I get why people don't use it. Looks really annoying
One of the worst decisions I made was using Fluent validations instead of Data Annotation in a project. Strongly recommend not using them, just creates unnecessary boilerplate that leads to people not using simple validations because it requires too much. code and the validation is separate from your domain so it's much harder to figure out required rules. Not to mention that any sort of generation (OpenAI) is not native and requires extra setup.
How do you have custom logic in the data annotation that requires resolving a service from the di container?
@@nickchapsas The question their is should you have that in your validation logic. For example, if you use CQRS that additional logic is related to your business rules, and you can use things like pipelines in mediator to separate it. But even that leads to double query problems like with exists validation on updates so there is a good case to be made you should keep it in your commands. To me validation is transferable between systems you should be able to do it on the frontend and the backend the same way and services mean you can't do it.
It doesn’t matter if you use CQRS or any other form of separation of concerns. Settings validation is infrastructure related not business logic related.
@@nickchapsas Yes but that is only true for validation rules that don't require you use services can you give me an example of a service you would need that isn't related to requirements coming from the concrete requirements of the project you are working on?
@@FilipCordas I think you both have a point. Nick is talking about the specific case of appsettings, you're talking about the concept in general and I think (if what I said is correct) that you are both correct.
First
Very useless to much work
booooooooooooooooooring !