Public client validator

[smolchanovsky]

Problem I want to make sure that my client interfaces are valid before running the app. So I want to write tests that will confirm validity. To do this, I need to create a client instance in the test method, since the client interface is validated when it is created. But in this case, I do not need to re-validate in runtime, it will be bad for performance.

Solution Currently, ClientValidator class is used for client validation, which is called when creating a client instance. You need to make it public and remove the client validation when creating it. It is worth noting that the validator uses IProxyGenerator. The implementation of this interface (ProxyGenerator) should be in a single instance:

Use of a single ProxyGenerator's instance: If you have a long running process (web site, windows service, etc.) and you have to create many dynamic proxies, you should make sure to reuse the same ProxyGenerator instance. If not, be aware that you will then bypass the caching mechanism. Side effects are high CPU usage and constant increase in memory consumption.

Checklist

• [ ] Make the ClientValidator public and easy to use
• [ ] Remove validation from the client creation logic
• [ ] Write tests for the validator (you do not need to test all invalid cases, just make sure that the validator works as expected)

[Kingmidas74]

In case of non-runtime validation we can run into consistency problem. For ex:

1. Write some code..
2. Run CI
3. Pass validation
4. Smbdy changes contracts of third-party service..
5. Our service has been started in non-valid state..

Suggestion: Keep current runtime checking in addition to ci checking. Bad for performance, good enough for stable

[smolchanovsky]

You're right, there is such a problem, but the client cannot know about the change in the contract of a third-party service. This problem can be solved by versioning the API (by the way, there are attributes for this). Here we are talking about the validation of the client interface. The interface may not be valid at all, for example, it may have several body parameters or it may pass a type to the path that cannot be correctly represented as a string.