Вы можете получить смешанные мнения, но, на мой взгляд, лучше всего проводить валидацию на обоих уровнях. В передней части и бизнес-логика (dlls, как вы это называете)
тавьте, что у вас есть приложение, которое является своего родавнешний интерфейс на всю вашу бизнес-логику. У этого внешнего интерфейса есть много библиотек DLL, от которых он зависит, и методы в этих библиотеках могут неоднократно вызывать друг друга при одном выполнении данного метода во внешнем интерфейсе. Если пользователи вашего приложения не имеют прямого доступа к этим библиотекам, следует ли вам ...
1) Риск (небольшого) падения производительности и проверки параметров в каждом из этих методов, даже если вы можете в итоге проверить одни и те же параметры примерно 5 раз; или же
2) Риск неожиданного поведения и предположите, что, поскольку вы проверяете входные параметры, все другие возможные параметры, переданные в и из вашего внутреннего кода, являются действительными (например, ни null, ни пустой)?
Редактировать: Просто чтобы привести пример, предположим, у вас есть регулярное выражениеRegexA и метод
internal bool Matches(string expression)
{
return RegexA.IsMatch(expression);
}
IsMatch сгенерирует исключение для нулевого параметра, но не для пустой строки. Если вы заранее знаете, что пустая строка никогда не будет соответствовать этому регулярному выражению, следует использоватьif (String.IsNullOrEmpty(expression)) прежде, даже зная, что это может быть проверено на ничтожность внутриIsMatch рамочный метод? В этом случае вы явно повторяете валидацию, но лучше ли ее повторять или рисковать?