我试图找出处理业务规则的最佳通用方法，其中规则并不总是可执行的 表单通过stored_procedure调用提交给数据库。目前，业务逻辑被写入stored_procedure而不是单独的业务应用层。存储过程返回包含错误和错误级别（信息，建议，警告，错误和致命）的数据集
信息只是为了更新可能需要的内容
建议允许用户中止更新/插入，但默认操作是继续
警告允许用户中止更新/插入，但默认操作是取消
错误违反了强制性业务规则，通常与数据完整性有关，并将强制取消更新/插入，但用户可以选择修改提交的数据并再试一次
致命是用户无法修复的东西（丢失了与数据库的连接，撤消了用户权限，自填充表单以来数据已更改等等）并将强制中止事务
这是我想要做的一个例子。
用于设置季节代码的表单
需要两种类型的验证：
强制性：例如代码和说明必须完整，且必须是唯一的，开始日期必须在结束日期之前
可选：开始和结束日期通常是有条件的，即下一季的开始日期将是前季节结束日期之后的第二天，但事实并非如此。我想警告用户他们有可能发生错误并让他们确认输入的数据是正确的。如果他们确认，那么我需要忽略重新提交的验证规则。
我认为存储过程中的一个额外参数忽略可选（信息和警告），如果用户确认问题正常，则仅在重新提交时设置。错误和致命仍然会导致更新失败。
有人可以提出更好的选择吗？
答案 0 :(得分：0)
您需要的只是执行类型业务规则，如果规则评估为True，则调用方法（规则操作）。该操作可以采用参数（例如，枚举ErrorLevel）并相应地执行操作，记录错误，通知用户，保存用户的条目等等）。类似的东西：
If UserRole is Admin and (StartDate is less than or equal to EndDate)
then Prosess(ErrorLevel.Info)
else Abort(ErrorLevel.Fatal)