您将如何使用业务验证层？

在我的项目中,我需要创建一个业务对象验证层,它将接受我的对象并根据一组规则运行它,并返回pass或fail以及它的失败原因列表.我知道有很多选择可以实现这一目标.

来自微软:

企业库验证应用程序块

Windows Workflow Foundation规则引擎

开源:

Drools.NET

简单规则引擎(SRE)

NxBRE

有没有人对这些技术(或任何我没有列出的技术)或任何他们认为最适合业务规则验证的意见有任何特别大的成功或失败.

编辑:我不只是询问通用验证字符串长度<200,邮政编码是5位数或5 + 4但是假设规则引擎实际上会被利用.

恕我直言,代码与规则引擎决策是一个权衡问题.一些例子是:

代码的优点

潜在的更高性能.

使用开发人员现有的技能.

无需单独的工具,运行时引擎等.

规则引擎的优点

(各种规则引擎的功能各不相同.)

规则DSL,由业务用户可写(或至少可读).

有效期限和到期日期属性,允许自动调度规则.

来自规则存储库的灵活报告支持改进的系统行为分析和审计.

正如数据库引擎将数据内容/关系问题与系统的其余部分隔离开来一样,规则引擎将验证和策略与系统的其余部分隔离开来.

CSLA框架规则的修改版本.

许多其他规则引擎的承诺类似于"最终用户可以修改规则以满足他们的需求".

Bahh.很少有用户会了解规则文档格式的复杂性,或者能够理解其更改的复杂性和后果.

另一个承诺是您可以更改规则而无需更改代码.我这么说呢？即使像"此字段不能为空"一样简单地更改规则也会对应用程序产生非常不利的影响.如果以前允许空白的那些字段,您现在在数据存储中有一堆无效数据.此外,现代应用程序可以是基于Web的,也可以通过click = once等技术进行分发/更新.因此,更新几个组件就像更新规则文件一样简单.

因此,因为开发人员无论如何都要修改它们,因为它们是Business对象操作的核心,只需将它们放在一个地方并使用现代语言和框架的强大功能.