Question

The following example is clearly fictional but it resumes how validation is done on a code base I’m working with.

TypeA has two methods, with the following signatures:

public void FirstMethod(TypeB param)
public ValidationResult TryFirstMethod(TypeB param)

When FirstMethod is called it needs to perform validation on the parameter.
Hence it calls TryFirstMethod to retrieve an object representing the validation’s result.
If the instance of ValidationResult says that everything’s OK the execution continues otherwise an exception is thrown.

The utility of TryFirstMethod is that the caller, an hypothetical TypeC, can execute this method and check if the actual method would throw. By examining a property on ValidationResult.
Also, the instance of ValidationResult contains information on why the input was wrong, how to fix it and so on.
This justifies the need for this type instead of just, say, using a boolean.

In practice this works fairly well, it’s quite easy to validate data and to return localized error messages to the user.

The only issue is that since certain checks are quite complex performing them two times becomes a little expensive.
They are initially done by the caller to make sure that the actual method won’t throw.
And then again by the method in question to check that the input is valid.

I can’t find a clean way to avoid having to perform the checks two times.
To make things more complex there is the fact that the solution should work with standard methods, constructors and also when TypeB is a “primitive” type like string or int.

Answer 1

It sounds like your core logic is something like this:

1. Validate TypeB (call TryFirstMethod).
2. If not valid, display error message.
3. If valid (and, presumably, other members are valid as well) then to perform operation on the data (as part of FirstMethod?).
4. The data operation (FirstMethod) re-validates the input.

If this is (somewhat) correct, you should be able to change your design into something like:

1. Call FirstMethod.
2. Validate data.
3. If invalid, throw validation exception.
4. If valid, perform data operation.

Your UI would then call FirstMethod and expect that the operation was successful unless an exception was thrown, in which case you’d display your validation messages as you do currently. With this design you only perform the validation a single time.