I won't comment on the Json stuff, as it doesn't seem to be the main subject to the question.
I'm not sure, I quite understand where to use this, so if you have a concrete real use case feel free to update the question with it.
You can't for instance use it in a switch like:
TestEnum te = TestEnum.Analyze;
Let me reflect to your other question, which is related to the good old ServicePointManager.
In the early versions of .NET Core they tried to get rid of the ServicePointManager and the related HttpWebRequest class as well. Instead they have introduced two new classes: WinHttpHandler and CurlHandler. Former should be used in Windows environment and latter ...
Some quick remarks:
if (mediaResultsAbove60Percent.Count == 0) return false; can be replaced by the much more readable return !mediaResultsAbove60Percent.Any();.
I'd extract parts of CreateEmailMessage to a separate method, or even class of its own, for instance a BodyRetriever class. Right now it does way too much.
You use bodyBuilder.HtmlBody yet the body ...
My first feedback about IFileValidator interface would be to have an Exists() method, just like how you're having one in IDirectoryValidator interface. Plus the Validator interfaces are doing much more than validation I feel. For example, it is also trying to get a list of subdirectories and files. It is good if Validators only handle the job of validations ...
In general the patch endpoint should consist of the following steps (order is important):
Preliminary check(s) (for example in case of null return BadRequest)
Load existing object (based on the request's key)
Apply the existing object (if any) onto the patch request
Validate model state (and return BadRequest if it is ain't valid)
Return with ...
Shouldn't the 'IsValid' method be static? I suppose you use it like Rule.IsValid(calculatedCompensation, 0, Rule.CompensationIsZero.Id), (as general idea, obviously it can be simplified).
Anyway PERSONALLY I would not do this, because Rule is no more an Enum, you gave it logic, that usually Enum don't have. I would have keep the Enum as original and built ...
What you're actually doing is implementing Service Locator which is quite opposite to dependency injection. Please refer to [THIS] discussion about it.
Please use already existing solution.
Few points from my side, just to point out why I think that's wrong for your case:
Why do you think you need more lightweight DI container? Have you performed ...
It's interesting to notice that when you parse your input, you break a comma-separated string into a list of values. The end result of your code can be achieved much more cleanly if you take a similar (but inverted) approach, i.e. generate a list of values and then have the comma-separated string generated from that list.
It's counterintuitive for the ...