Doing basic prevalidation before calling a validation service seems to be an acceptable approach. Personally I try to avoid building too much logic in a validation. If a rule can’t be built as a simple pattern or sets of patterns, it’s maybe the case to use another approach. Sure, one has sometimes to compromise or be inventive… I met cases in which a rule wasn’t so easy to write, especially as an SQL query. Some of these were cases in which a way to standardize the values was necessary. Then one has to check with the business if something can be done in this direction.

If the validation against a service takes time, one can use the second approach I mentioned – use row data from a data provider. For this is enough to load the data in an internal database and have the data synchronized on a weekly basis or on demand when needed. I prefer this second approach because is fast, reliable and can be used against multiple systems. It is sufficient to store postcodes, streets, regions, countries and cities. One can use these data for a full validation, or for a prevalidation before accessing a validation service.

I’m also trying to avoid hardcoding too many values. I prefer to store the values I use for validations in a table that’s easy to maintain by me or users.

Some validations can be built also “asynchronously”, done e.g. against a copy of the source data.