Why not leave the data in the DTOs and pump them through a rules engine like the ones in Biztalk Server or Windows Workflow Foundation or any number of third party rules engines?
No sense writing your own batch processing engine when you can use something that's a commercially supported product.
I guess I'm missing something!
Internal, hard-wired example:
ValidationRules.AddRule(CommonRules.StringRequired,"LastName");
External, data-driven example:
(I'm guessing on the syntax here - especially the TypeOf code - I haven't done this, and I'm assuming that we've done a business object and business object collection to make the list of rules available in a c# environment:
// Load the rule data collection
RuleDataList ruleDataList = RuleDataList.GetList(TypeOf(this));
foreach (RuleData ruleData in ruleDataList)
{
ValidationRules.AddRule(SomeConversionFunction(ruleData.RuleMethod),ruleDataArguments);
}
SomeConversionFunction would take the string representation of the rule method and turn it into the technical equivalent of CommonRules.StringRequired in the first example.
Is that what you are talking about? The data source for RuleDataList could be an xml file or a database table, whichever was more convenient.
David,
What I picture is something like this:
So given a class Customer with properties Name and Account, I would expect to get a serialized version similar to:
<Customer>
<Name>David</Name>
<Account>123</Account>
</Customer>
The business rules say that your name is required and your account must be 4 characters in length and must be numeric. Your business rules XML would look like (though not exactly since you could be as granular as you wanted):
<?xml version="1.0" encoding="utf-8" ?>
<Rules>
<RuleGroup RuleGroupID="CustomerRules" Context="/Customer">
<Rule RuleID="NameLength" IsEnabled="True" Property="Name"
RuleText="//Customer[string-length(Name) = 0]/Name"
Message="Your name is required." />
<Rule RuleID="AccountValue" IsEnabled="True" Property="Account"
RuleText="//Customer[string-length(Account) != 4 or string(number(Account)) = 'NaN']/Account"
Message="The account number specified is not valid. Please check the account number." />
</RuleGroup>
</Rules>
The code I wrote will load this xml file into an object hierarchy. It goes through and executes the Context XPath query to see if their is any need to run the following rules. The rule group "CustomerRules" will identify any Customer nodes that are the root nodes of a document. If any are found, then you can run the other rules. As I execute them, I raise an event if they return a node and give detailed informaton about the error including the friendly Message to display.
Our system is not performance critical, but it is a web application that must respond to a user in a somewhat timely fashion. My initial tests show this as being quick enough that I do not have to worry so much about performance, and that is without having applied any optimizations.
This idea came about after seeing business rules scattered around two similar interfaces, many of the rules out of date. It may not be viable at all for building a scalable flexible application, but I wanted to get some feedback from others before buying into or dismissing the idea altogether.
Thanks in advance.
Christian
This sort of thing is why CSLA 3.0 has the DecoratedRulesArgs
class btw.
The idea is that you can use reflection to do the work, rather
than coding anything beyond the rule methods themselves.
<Rule type=”Csla.Validation.CommonRules, Csla” method=”StringRequired”
/>
<Rule type=”Csla.Validation.CommonRules, Csla” method=”StringMaxLength”>
<Parameter name=”MaxLength” type=”Int32”
value=”20” />
</Rule>
<Rule type=”MyApp.Rules, MyApp.Library” method=”AwesomeRule”>
<Parameter name=”MinValue” type=”Int32”
value=”20” />
<Parameter name=”MaxValue” type=”Int32”
value=”100” />
<Parameter name=”Randomize” type=”Boolean”
value=”True” />
</Rule>
Or variations along that line. The point being that you can
easily write a single bit of code that can parse a <Rule> node and create
everything you need to call AddRule() – specifically a delegate pointer
and a DecoratedRuleArgs object.
Rocky
I've been building a webcontrol that reads the list of rules and automagically adds the validators necessary to enforce them.
That's why I'm particularly interested in learning how to assign the rules from a database, it allows me to add all non-custom rules without coding or re-deploying the application, and to disable any already coded rule in the same way. In combination with my new webcontrol, I'm hoping to reduce the coding/testing/deployment/maintenance effort of business rules to about 5% of what it currently is.
RockfordLhotka:
The point being that you can easily write a single bit of code that can parse a <Rule> node and create everything you need to call AddRule() – specifically a delegate pointer and a DecoratedRuleArgs object.
Rocky
Full details are coming in the Using CSLA .NET 3.0 ebook,
but this is how you use it in AddBusinessRules():
Csla.Validation.DecoratedRuleArgs
args =
new Csla.Validation.DecoratedRuleArgs("Name",
"Project name");
args["MaxLength"]
= 50;
ValidationRules.AddRule(
Csla.Validation.CommonRules.StringMaxLength,
args);
And you can look at the 3.0 CommonRules class to see how to
implement a rule that accepts DecoratedRuleArgs (or a subclass of it anyway – I
had to do some fancier than normal work to preserve backward compatibility)
rather than RuleArgs.
The important thing is that the rule method MUST accept a
DecoratedRuleArgs parameter for this to work.
Rocky
From: un7lg
[mailto:cslanet@lhotka.net]
Sent: Friday, August 10, 2007 3:47 PM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: Xml based business rules