代码之家  ›  专栏  ›  技术社区  ›  Hemanshu Bhojak

持久层验证

  •  0
  • Hemanshu Bhojak  · 技术社区  · 15 年前

    在使用存储过程保存数据时,我们经常会遇到外键约束、唯一键约束等。通过传递正确的数据,可以纠正所有此类错误。

    验证可以在业务逻辑层中完成,只有在成功的情况下才应该发送到持久性层。但在某些情况下,在保存数据时验证数据很方便。就像在存储过程中一样。

    例如,如果用户输入一些日期范围值,则应验证该范围是否与任何现有范围重叠。在这种情况下,最好返回一些错误代码,可以告诉我们范围是否重叠且无法保存。

    在SQL Server中,我们可以简单地引发自定义异常,但我希望不使用异常。是否有任何我可以使用的验证框架。

    我正在寻找一个SQL Server 2005和。net特定的解决方案。


    附笔。: 我通常从存储的进程返回自定义错误代码,然后通过查找xml文件解析它们,然后在我的业务层规则引擎中使用它。

    1 回复  |  直到 15 年前
        1
  •  2
  •   Steve    15 年前

    在SQL Server中嵌入业务逻辑可能会提高性能,但会因为违反关注点分离而使设计复杂化。为了让我拥有可移植的业务逻辑,它应该位于业务层。我会从存储的进程中删除验证逻辑,只使用它们来简化CRUD操作。你永远不知道项目涉众什么时候会说“让它在数据库X上运行!”。尽最大努力保持验证逻辑数据库的独立性。