After researching a couple of 3rd-party business rules engines, it has become apparent to me that there is a big difference between the way these tools view business rules and the way things are being done in CSLA where, despite having methods called "AddBusinessRules" and "AddInstanceBusinessRules", we are strictly dealing with Validation Rules. These being solely for the purpose of validating the values contained in our BO properties as opposed to implementing "if-then do this" type business rules as seems to be the way these tools are designed to behave.
Has anyone attempted to use any of these business rule engines and, of so, what do you think? Do they play well with CSLA? Any recommendations on which one(s) I should take a look at?
Thx
I've discussed this before a couple times. The challenge with these external rule engines is that they assume "objects" are innocent, helpless containers for data. They assume they can do anything to the object, and the object won't object. No concept of encapsulation.
But that's OK for batch processing or block mode UI's (like the web), because there's no need to have per-property interactivity in those environments. And in that case these external rule engines can be better than a CSLA approach, because they can often be smarter about how and when they apply various rules and how they alter the object data, etc.
The approach used by CSLA is really geared toward interactivity.
I've talked to the .NET WF team, and they live in a non-interactive world. It is really hard to get them to even understand the idea of validating a property and deciding if it is valid. Or calculating a property value. They think at the object level.
I asked how they'd implement IDataErrorInfo - which drew blank looks. They are so removed from the UI that they didn't know what it was ![Smile [:)]](/emoticons/emotion-1.gif)
Which is fine - they are building a technology for one thing, and I'm very focused on a different thing.
I imagine some rule engines might be more capable of CSLA-style interactivity, but I think that'd be the exception, not the rule.
On the other hand, if you were building a web app only and never planned to support Windows, WPF or Silverlight, then I think a pretty good argument could be made that a rules engine might be a better overall solution than CSLA - at least in regards to this particular area of functionality.
So, in your eyes there is no difference between validation rules and business rules in the way things are implemented in CSLA? I guess I can see that and am struggling to find an example in all of my use cases where this isn't the case until I step into the workflow realm - as you touched on. After reading your response and looking back at a couple of the "rule engines," I would agree that these are nothing more than workflow engines. And you are absolutely right about the lack of encapsulation.
I guess the one selling point that had grabbed my attention was the ability to manage the rules outside of code. I deal with a LOT of ambiguity, change and personalization issues so the idea that the app's behavior could be tweaked without recompilation and redistribution (or having to teach how to manage an app.config file!) was appealing.
I do think it is important to recognize that some “business
rules” are enforced/implemented by the very nature of your object
relationships within the model.
The fact that an order contains line items that contain detail
items is a whole set of business rules. The act of creating an order
Order order = Order.NewOrder(customer);
has some business rules embedded in the very nature of the relationship.
To create an order you must have a customer. The order creation process uses,
and relies on, a valid customer.
These natural consequences of using a domain object model are
things that a rules engine would need to explicitly implement in many cases.
So yes, there are different types of rules – simple validation,
calculation, etc. And rules that flow from the very relationships between
objects. I honestly don’t think there is substantial difference between
validation and business rules. Certainly they are both of critical importance,
and they both must be implemented in the business layer, and you can’t
have “business rules” without validation rules (or you have GIGO).
Rocky
From: SonOfPirate
[mailto:cslanet@lhotka.net]
Sent: Monday, December 03, 2007 7:07 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] Business Rules vs. Validation Rules
So, in your eyes there is no difference between validation rules and
business rules in the way things are implemented in CSLA? I guess I can
see that and am struggling to find an example in all of my use cases where this
isn't the case until I step into the workflow realm - as you touched on.
After reading your response and looking back at a couple of the "rule
engines," I would agree that these are nothing more than workflow
engines. And you are absolutely right about the lack of encapsulation.
I guess the one selling point that had grabbed my attention was the ability
to manage the rules outside of code. I deal with a LOT of ambiguity,
change and personalization issues so the idea that the app's behavior could be
tweaked without recompilation and redistribution (or having to teach how to
manage an app.config file!) was appealing.
A question about bussines / Validation rules.
Is correct to call business rules the fact of, for example, to update stock or client balance, After updating an object like bill?
Is correct to put this on object domain or is better delegate this to database rules?
I'm puting this actions don Dataporta_XYZ methods using objects for this purpose.
Copyright (c) Marimer LLC