在我的项目中,我需要创建一个业务对象验证层,它将获取我的对象并针对一组规则运行它,并返回pass或fail以及它的失败原因列表。我知道有很多选择可以实现这一目标。
来自Microsoft:
开源:
有没有人对这些技术(或任何我未列出的技术)或任何他们认为最适合业务规则验证的意见有任何特别大的成功或失败。
编辑:我不只是询问通用验证字符串长度< 200,邮政编码是5位数或5 + 4但是假设实际上会利用规则引擎。
答案 0 :(得分:6)
代码与规则引擎的决定是权衡问题,恕我直言。一些例子是:
(各种规则引擎的功能各不相同。)
答案 1 :(得分:5)
CSLA框架规则的修改版本。
许多其他规则引擎的承诺类似于“最终用户可以修改规则以满足他们的需求。”
Bahh。很少有用户会了解规则文档格式的复杂性,或者能够理解其更改的复杂性和后果。
另一个承诺是您无需更改代码即可更改规则。我这么说呢?即使像“此字段不能为空”一样简单地更改规则也会对应用程序产生非常不利的影响。如果以前允许空白的那些字段,您现在在数据存储中有一堆无效数据。此外,现代应用程序可以是基于Web的,也可以通过click = once等技术进行分发/更新。因此,更新几个组件就像更新规则文件一样简单。
因此,因为开发人员无论如何都要修改它们,因为它们是Business对象操作的核心,只需将它们放在一个地方并使用现代语言和框架的强大功能。
答案 2 :(得分:3)
我真的不喜欢Microsoft提供的规则和验证块(过于复杂和不灵活),所以我必须根据自定义业务工作流引擎的经验构建我的。
经过几次迭代后,该项目终于开始使用Open Source(BSD许可证),并且在生产系统中证明是有用的。 .NET Application Block for Validation and Business Rules的主要功能:
以下是UI级别的规则的简单绑定:
注意,目前的实现目前没有任何DSL。 C#语法本身足够表达,因此没有要求在顶部添加基于Boo的DSL。
答案 3 :(得分:2)
我必须承认,对于非常简单的验证,我倾向于编写我自己的非常小的紧凑规则引擎,主要是因为我认为使用其他人的实现对于一个小项目来说是不值得的。
答案 4 :(得分:1)
我已经尝试使用Workflow Foundation,使用了EntLib,并编写了自己的规则引擎。
在我只需要进行基于UI的验证以确保无效数据不会潜入数据库的小型应用程序中,我可以访问EntLib验证块。它易于使用,并且在我的域对象中只需要最少量的代码,而且它不会弄乱NHibernate或我的技术堆栈中的任何其他东西。
对于复杂的东西,域层验证等,我很容易选择再次编写自己的规则引擎。我更倾向于在代码中编写规则,每个规则都在它自己的小类中,易于测试并且非常简单地组成复杂的规则集。
在我编写这种规则引擎的大型应用程序中,我们然后使用FitNesse来测试我们的规则配置。使用这种工具来确保正确性非常棒。我们可以提供表格和数据表,并确切地知道我们配置的规则有效。
答案 5 :(得分:1)
如果您有兴趣自己动手,请阅读JP Boodhoo关于规则处理的帖子。基本上,他提出了一个用于验证域对象的直接框架。
答案 6 :(得分:1)
尝试
http://rulesengine.codeplex.com
它是轻量级的,使用流畅的接口来定义验证逻辑,可扩展和免费! 您甚至可以在接口上定义规则,实现者继承规则。
不再烦人的属性风格验证 - 你没有拥有你想要验证的类
它有一个Asp.Net MVC插件(仅限服务器端)。
还有另一个名为Polymod.Net的项目,它使用RulesEngine来提供自我验证的UI,如屏幕截图所示!
答案 7 :(得分:0)
企业库验证块提供了一种非常类似AOP的方法,并且根据我的经验在3.1和4.1中保持简单。
答案 8 :(得分:0)
我建议使用CSLA Framework。不仅用于验证,还用于其他功能。