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

【问题标题】：parameter validation, stored procedures and data access layer in c#c#中的参数验证、存储过程和数据访问层
【发布时间】：2011-12-18 20:46:16
【问题描述】：

我使用以 c# 和 sql server 数据库作为数据源的三层架构。根据 DRY 原则，验证应该只在一个地方完成，在我的例子中是前端数据访问层或数据库存储过程。

所以我想知道是验证数据访问层中的存储过程参数还是将其留给存储过程本身？？

【问题讨论】：

标签： c# asp.net sql-server stored-procedures

【解决方案1】：

DRY 是一个重要原则，defence in depth 也是如此。

在验证输入时，您必须确保它是安全 - 这应该在每个级别上完成（在 DAL 和存储过程中都是如此）。

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

【讨论】：

所以你建议选择深层干燥？因为这两者有很大的不同。
@jim - 这是一个判断问题。你必须决定什么对你更重要。

【解决方案2】：

如果您使用的是三层架构，我建议您使用 ORM 进行调查，例如 Nhibernate 或 Linq to Entites。 ORM 将为您提供更好的重构能力和可维护性（根据我的经验，可维护性对我来说是最重要的，因为从长远来看，它会带来质量）。

将您的验证放入 UI 是不明智的，因为在您的 DAL（数据访问层）中设置安全性比在更容易绕过（意外或故意）的 UI 中更安全.想想 SQL 注入。您应该验证您的数据访问权限，而不是仅验证您的 UI，因为它很容易在您的 UI 上遗漏，并且很容易绕过恶意用户试图访问他们不允许访问的其他数据的访问权限。

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

【讨论】：

我正在使用带有存储过程的 ORM。这就是我问参数的原因。您在 UI 或 BLL 中验证它们一次。那为什么又在 sp 里面呢？
深度防御。您应该假设任何层都可以被绕过。我认为有一个比喻，防守应该像洋葱一样，分层多层次。