c#中的参数验证、存储过程和数据访问层

DRY是一个重要的原则，但纵深防御也是如此。

当涉及到验证输入时，您必须确保它是安全的 -这应该在每个级别上完成(因此在DAL和存储过程中都是如此)。

至于为业务逻辑验证数据，这应该在您的业务逻辑层(BLL)中。

如果您正在使用三层架构，我建议您研究使用ORM代替，例如Nhibernate或Linq to entities。ORM将为您提供更好的重构能力和可维护性(可维护性对我来说是最重要的，因为根据我的经验，从长远来看，它会导致质量的提高)。

将验证放在UI中是不明智的，因为将安全性放在DAL(数据访问层)中比放在UI中更安全，因为它更容易被绕过(意外或故意)。想想SQL注入。你应该对你的数据访问进行验证，而不是只对你的UI进行验证，因为它很容易在你的UI上被忽略，并且很容易被恶意用户绕过，试图访问他们不允许访问的其他数据。

我认为在UI上进行可用性验证和在数据访问层进行安全性验证可能是有意义的。我确实喜欢DRY原则在一个地方做验证，你仍然可以这样做。如果你制定了一套通用的规则，并将其传播到数据访问层和UI，那么你将拥有一个安全且可用的系统(通过对数据输入的即时反馈)。另一种方法是为不同的层设置不同的规则。例如，字段长度规则和数据输入模式可以是特定于UI的。例如，DAL可以强制数据是有效的。这是在多个地方做验证，但只要他们不是独立地做同样的事情，我认为你会没事的。这是设计应用程序时要考虑的最困难的领域之一，因为验证是一个横切关注点，如何进行验证在很大程度上取决于您如何构建应用程序设计的其余部分。