持久层验证

Question

使用存储过程保存数据时，我们经常遇到外键约束，唯一键约束等。所有这些错误都可以通过传入正确的数据来纠正。

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

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

在SQL Server中，我们可以简单地引发自定义异常，但我想在不使用异常的情况下执行此操作。是否有我可以使用的验证框架。

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

---

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

Answer 1

在SQL Server中嵌入业务逻辑可能会提高性能，但会通过违反关注点分离来使设计复杂化。为了让我拥有可移植的业务逻辑，它应该在业务层中。我将从存储过程中删除验证逻辑，并仅使用它们来使CRUD操作更容易。你永远不知道项目利益相关者什么时候会说“让它在Database X上运行！”。尽力保持验证逻辑数据库的独立性。