Silky,
I have to disagree with you...
C#/VB is not the cure to all problems; there are other languages out there!
I have not used a business rules language as such, but I can see real value
in a language where you can show an end user the source code of a set of
business rules like...
TotalClaims = Sum ( ClaimItems )
If TotalClaims > ClaimLimit Then ClaimLimitExceeded
You should be able to get your client user to sign off on code like the
above, but try asking them to sign off on...
public bool ValidateClaimLimit( Claim aClaim )
{
decimal lTotalClaim = 0;
foreach ( ClaimItem lItem in aClaim.Items )
{
lTotalClaim += lItem.Value;
}
bool lResult = lTotalClaim < _ClaimLimit;
return lResult;
}
If the business rules code can be read and understood by a client user and
compiled into executable code by a business rules engine, then I see real
value for it.
You say...
> you need to:
> 1. Understand them
> 2. Know how to program them
> 3. Test them
I would say that you need to:
1. Review the rules
2. Document the rules
3. Understand the rules
4. Program the rules in a machine executable format
5. Test the rules
Your 1&2 are effectively my 1-4.
All of the steps would greatly helped or effectively eliminated by having
some form of rules engine.
So, I see real value in the question “what are the Tools/Methodologies to
categorise/Implement business rules in .net?”
Interesting to note that a quick search of Google gives 24M results for the
search “dot net business rules engine”.
Regards
Greg Harris
On Fri, Feb 26, 2010 at 11:21 AM, silky <michaelsli...@gmail.com> wrote:
> On Fri, Feb 26, 2010 at 11:07 AM, Arjang Assadi <arjang.ass...@gmail.com>
> wrote:
> > what are the Tools/Methodologies to categorise/Implement business
> > rules in .net?
>
> Honestly, isn't *every* rule a business rule?
>
> Shouldn't you just handle it via, you know, development?! And then
> test it via unit testing? I don't understand all this timewasting
> rubbish about spec'ing it out in some language that you then need to
> test in-and-of-itself and then have that generate it in yet another
> lower language.
>
> You haven't solved anything with that approach anyway. You've just
> shifted your problem. It's good sometimes, it's bad sometimes, it's
> not an answer to the underlying issue that to implement "Business
> Rules" you need to:
>
> 1. Understand them
> 2. Know how to program them
> 3. Test them
>
> This is our job - this is the purpose of programming. Converting ideas
> into things, and things into useful things, working things, correct
> things, and fun things.
>
>
> > There are just too many combinations / degrees of freedom in
> > translating business rules into implementation, but surely by now a
> > more holistic has come to being, anyone knows where or how to find
> > them ?
>
> Yes - your brain. It is the translation mechanism.
>
>
> > Regards
> >
> > Arjang
>
> --
> silky
>
> http://www.programmingbranch.com/
>
