12

在我的项目中，我需要创建一个业务对象验证层，它将获取我的对象并根据一组规则运行它并返回通过或失败以及失败原因列表。我知道有很多选择可以实现这一点。

来自微软：

开源：

是否有人在使用这些技术（或我未列出的任何技术）方面取得了特别大的成功或失败，或者对他们认为最适合业务规则验证的技术有任何意见。

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

4

9 回答 9

6

The code-versus-rules-engine decision is a matter of trade-offs, IMHO. A few examples are:

Advantages of code

  • Potentially higher performance.
  • Uses developers' existing skills.
  • No need for separate tools, run-time engines, etc.

Advantages of rule engine

(Features vary across the various rule engines.)

  • Rule DSL that is writable (or at least readable) by business users.
  • Effective- and expiration-date properties that allow automatic scheduling of rules.
  • Flexible reporting from rule repository supports improved analysis and auditing of system behavior.
  • Just as data-base engines isolate data content/relationship issues from the rest of the system, rules engines isolate validation and policy from the remainder of the system.
于 2009-02-09T02:16:33.180 回答
5

A modified version of the CSLA framework rules.

Many of the other rules engines have the promise that goes like "The end user can modify the rules to fit their needs."

Bahh. Very few users are going to learn the complexities of the rules document format or be able to understand the complexities and ramifications of their changes.

The other promise is you can change the rules without having to change the code. I say so what? Changing a rule even as simple as "this field must not be blank" can have a very negative impact on the application. If those fields where previously allowed to be blank you now have a bunch of invalid data in the data store. Plus modern applications are either web based or distributed/updated via technologies like click=once. So you updating a couple of components is just as easy as updating a rules file.

So, because the developer is going to modify them anyway and because they are core to the Business objects operations just locate them in one place and use the power of modern languages and frameworks.

于 2009-02-14T05:04:57.433 回答
3

我真的不喜欢微软提供的规则和验证块（太复杂和不灵活），所以我必须根据自定义业务工作流引擎的经验来构建我的。

After a couple of iterations the project has finally gone Open Source now (BSD license) and has proven helpful in production systems. Primary features of .NET Application Block for Validation and Business Rules:

  • Simple to get started with
  • Rules for the domain objects
  • Rule Reusability
  • Predefined Validation Rules
  • Behavior Extensibility
  • Proper object nesting
  • Designed for DDD and UI level validation
  • Multiple reporting levels
  • Production-proof and active development
  • Small codebase
  • Open Source

Here's how a simple binding of rules at the UI level looks like:

Binding Rules to UI

Note, that current implementation does not have any DSL at the moment. C# syntax is expressive enough on its own, so there has been no demand to add Boo-based DSL on top.

于 2009-02-08T08:52:35.087 回答
2

我不得不承认，对于非常简单的验证，我倾向于编写自己的非常小的、紧凑的规则引擎，主要是因为我认为使用别人的实现对于一个小项目来说是不值得的。

于 2009-02-07T22:08:15.807 回答
1

I've experimented with Workflow Foundation, used EntLib, and written my own rules engine.

In small applications where I only really need to do UI-based validation to ensure invalid data doesn't sneak into the DB, I reach for the EntLib Validation Block. It's easy to use and requires only a minimal amount of code in my domain objects, plus it doesn't mess up NHibernate or anything else in my technology stack.

For complex stuff, domain-layer validation, etc., I'd easily opt to write my own rules engine again. I'd much rather write rules in code, each rule in it's own tiny class, easily testable and very simple to compose complex sets of rules with.

In the large app that I worked on where I wrote this sort of rules engine, we then used FitNesse to test our rule configurations. It was great having that kind of tool to utilize to ensure correctness. We could feed it tables and tables of data and know, with certainty, that our configured rules worked.

于 2009-02-12T05:12:37.010 回答
1

If you are interested in rolling your own, read JP Boodhoo's post on Rules processing. Essentially he lays out a straight forward framework for validating domain objects.

Validatiion in the Domain Layer

Validation in the Domain Layer 2

于 2009-02-15T18:00:12.403 回答
1

Try

http://rulesengine.codeplex.com

It's lightweight, uses fluent-interfaces to define validation logic, extensible, and Free! You can even define rules on interfaces, implementors inherit the rules.

No more annoying attribute-style validation - what it you don't own the class you want to valida

It has a plug-in to Asp.Net MVC (server-side only).

There is also another project called Polymod.Net which uses RulesEngine to provide self-validating UI's as shown in the screen-shot!

于 2012-03-16T05:34:12.903 回答
0

Enterprise Library Validation Block 提供了一种非常类似于 AOP 的方法，并根据我的经验在 3.1 和 4.1 中保持简单。

于 2009-02-07T22:14:00.210 回答
0

I recommend using CSLA Framework. Not only for Validation but for other features also.

于 2009-02-12T05:22:34.897 回答