On Fri, Feb 26, 2010 at 12:44 PM, Greg Harris <harris.gre...@gmail.com> wrote:
> Silky,
>
> I have to disagree with you...

Be my guest.


> C#/VB is not the cure to all problems; there are other languages out there!

I never said otherwise.


> 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 really show your end users/clients, code? Instead of outlining all
of what has been tested (i.e. scenarios)? I don't think showing "real
people" code like the above is particularly useful (or even good).

[...]


> 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.

I disagree. I think you've just moved your "code" into a "new
language". So you can program in a new language, so what. Do it or
don't do it, what do I care. It's just a different language. Present
your information to clients/managers however is best for them. If they
understand the statements of a basic programming language, good.
Probably, they don't, because it may be hard to convey edge cases, or
context, or they will assume various things that aren't true.

Whatever works, really. I took issue with the idea there is some
magical modelling process you can do to make your code suddenly
correct. The process is called "programming" and it can take place in
whatever language is appropriate. Maybe two languages, if it's
relevant (one to generate an implementation in other). This is fine,
if it works. I don't have any strong opinions about it.


> 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”.

I've never based my opinion on what the majority of people do, or even
what some sort of subset of people do; I base it only on what I think
via the opinions formed from experience and research. Wrong or right,
it's the way I operate. So I really don't care that there may be
"demand" for it.


> Regards
>
> Greg Harris

-- 
silky

  http://www.programmingbranch.com/

Reply via email to