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. ;)
Рік тому+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.
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)?
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.
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.
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 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?
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?
@@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 UA-cam membership for your channel?
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
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.
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
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.
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.
@@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.
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.
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. ;)
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 ;)
❤ 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.
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)?
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.
i will incorporate this into my current project, this could save me headaches later
You are the best, even better than chat gpt
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'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.
I always wanted to make a code generator to auto create json schema for an option class so you get validation and auto complete.
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)
Hats off Nick Chapsas!
I love this approach. Thanks for sharing.
Would be neat if there were an additional fluent validation nuget package for this
Love your videos. Never stop making them ))
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?
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?
Why do you use AddOptions and Bind methods? There is an overload of Configure method which accepts IConfiguration
This is very very good! Thanks Nick
Right on lunchtime 👌
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 UA-cam membership for your channel?
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
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.
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
Very nice..Lot of good things learning from you..
This looks like it would mix well with IValidatableObject does that happen automatically?
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?
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.
What would be the solution do turn this off if it is on "developer machine" ?
How to add data annotation for a string that take http/https endpoint as a setting , to validate using ValidateDataAnnotations()
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 ? 🤔
This cannot be done in an Azure Function App since it doesn’t use the Hosting package. Any workaround?
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.
Awesome content as usual!
This is going over my head. It tried but didn't understand why it is used.
Still waiting for ConfigureAwait vid
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
You would have that exception on startup if you registered the setting class as a singleton
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
Awesome!
Thanks 👍
Hi Nick!
Small heads up; theres a typo in the description
“settions” presumably in stead of “settings”
Cheers
Nice and clear way to validate settings 👌. Thanks Man
Very cool!
Ungh... Back in my days, developers copied code only from verified sources, such as StackOverflow. Never from the official framework... ☹
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.
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
It looks like fluent validation is still the best approach in .NET 8.
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 !