The NEW Way of Validating Settings in .NET 8
Vložit
- čas přidán 30. 07. 2023
- Check out my courses: dometrain.com
Become a Patreon and get source code access: / nickchapsas
Hello everybody, I'm Nick, and in this video, I will show you the new and upgrades Options or Settings Validation that's coming in .NET 8.
Workshops: bit.ly/nickworkshops
Don't forget to comment, like and subscribe :)
Social Media:
Follow me on GitHub: bit.ly/ChapsasGitHub
Follow me on Twitter: bit.ly/ChapsasTwitter
Connect on LinkedIn: bit.ly/ChapsasLinkedIn
Keep coding merch: keepcoding.shop
#csharp #dotnet
We do use options validation and would rather take the hit at startup to ensure the app settings are correct. I don't like the idea of finding out you have bad config at runtime, that's how you end up with a prod deployment that starts throwing errors 😅
100% agree
TIL about the ValidateOnStart, how did I not know about this?
yeah
But on the other hand you‘re throwing up the whole application instead of certain feature-specific endpoints. Maybe even as late as in production. We‘re also discussing this…
@@timmkrause6684 That would not reach the users in production because the health checks won't work if the app doesn't start
You forgot to show how to get valudation on start with the new setup
You could do it like this in Program.cs
var app = builder.Build();
var myClassValidator = app.Services.GetRequiredService();
var myClass = app.Services.GetRequiredService();
myClassValidator.Validate(null, myClass.Value);
So once you have the app instance, get the injected values of the validator and configuration options and call the validator's Validate method that's generated from the source compiler.
I usually don't use them but I'm kinda sort of thinking about them and thank for the info and opion👍
thx Nick, I will use it when I get back to work in a week... ! :)
One could write a convention- and reflection-based unit test though to check all necessary meta types exist and attributes are set correctly to make it less prone to errors.
I like the fact that the validation is decoupled from the object itself. You can have a class from a different project annotated with standard attributes and have a validator in an API project.
What prevents you from making the settings class public and implementing this interface? Will it fail compilation?
You can do .BindConfiguration(ExampleOptions.SectionName) directly btw.
How are you. Bless to use required and init? I get errors in .net 7 did they also fix that in .net 8?
I agree with you that validation should be directly on the actual Options object. Why go with this anemic classes? Validator is so tightly coupled with the object it validates, why not be the same class?
They could implement the generator to also work with ExampleOptions implementing the IValidateOptions directly. Maybe they did?
I’ve run into situations where I needed two different validators for the same class. Obviously for this SPECIFIC use case it doesn’t seem to matter, but it makes sense why they’d want to leave that open.
Your "Options" class is simply just a DTO though. Most people would not add validation to their domain classes or Entity (framework) classes, but choose separate validators. This is not different. The validation is also only needed by the Options framework for loading and reloading. When injected into your code you would not need any of the validation logic exposed.
@@chris-pee Yeah, I think this would be the right approach, give the developers the option to use the same class or a different class.
@@paulkoopmans4620 You could explicitly implement the IValidateOptions, which would make those methods invisible to your code.
Already built this as part of a set of extension methods for Bind() in earlier versions of .NET Core; the proposed solution is complex and requires a lot of moving parts, where instead the simple approach is to attempt to resolve and validate the bound type straight after the Bind() operation. It's as simple as that.
Hey, thanks for the video. Can you please confirm if .http file can contain link to another .http file so that we don't have to repeat the common api call like login?
I just added the app settings class as a singleton on startup
can this be used for data validation in general?
Seems like good step, but yes I agree there is too much bloated code flying around, so many classes in addition, I would also see it like my options class can be made partial and then auto generated for validation, because why not. The same showstopper I found in Mapperly, you can't decorate and get generated mapper within a class which you'd like to map, but you need separate type for that.
Until 20th July? It’s 31. So it’s over?
Forgot to remove the ad sorry for that
great 👏👏👏
Great video, that was the best and quickest overview ever. I think I learned/understood more/better that time than the first time I saw in the original video. But on the scale of things, how important is Startup time perfs, and is this really the place where .Net Core needed attention. I do not mind being put in my place here, but I am curious. I do agree it is a little verbose. It seems that the generator should be able to detect the nested JSON objects and create those extra classes on the fly for the user. Am I wrong here too? Great video.
It is if you use serverless.
I have been asking this question for almost two years now, after, "If you like content..."... What is that you are saying? Putting on subtitles gives random results every time. It has even gotten to to a meme at my work, when we post screen shots of CZcams subtitles to our Teams channel. 🙂
And now I can't unhear it. Curse you.
@Nick, you published this video yesterday and the coupon code is already expired. What's up with that?
I'm agree with you, and I have question, .net is focusing on native aot and there is problem what about our old code base? What if we wanna get aot native with them there are thousands of features that are using reflection!?!
You need to progressively modernize your code.
Could you have the partial class implement multiple interfaces for the different option types? That way you don't have multiple classes for each one.
No link to the github issue?
Clock.SetNow(new DateTime(2023, 07, 19));
I tend to avoid using IOptions as I can easily inject the singletons myself without a wrapper.
I also see no point in validating the settings.
If someone could give me some good arguments favoring the recommended approach 🙏
What if the options are updated or changes on the fly without app restart .Singleton won't cater for that.
You are right that in the simple case of just needing static configuration, IOptions isn't kind of redundant. IOptionsSnapshot
I use options and have used validation on startup. However, I prefer to separate options from configuration i.e. not simply binding to configuration. This decouples Options from the configuration store. I can tailor Option classes to use cases, where a number of these classes may share configuration values and may curate their option values from various places in the configuration.
Reflection is slow on a computer nanosecond scale but not on a human scale. Who cares if the app takes an extra fraction of a millisecond to start up?
I agree its gonna be a big mess.
What really bugs me, is that we had strongly typed settings decades ago. You just set them in the project properties, and you were done. True, they weren't hierarchical, but they were more than good enough for me, and required no code whatsoever. Why do things have to be so convoluted these days?!
This new approach looks dirty
Wouldn‘t shift to that approach. Too much overhead.