Mike,

>

public bool IsRecordValid()
>{
>   return name != "";
>}

>
>Thats my business rule, now, when I introduce the framework:
>
>1. What will this code look like?
>2. Will it be as easy to modify as the existing code?
>(Lets say we change the business rule to return name + firstName != "", does the business rule implemented as an object adapt as easily?)
>3. What do I gain using the new way and not simply coding the rule in a straightforward manner that all C# developers will understand?

It may be more easy to give a brief explanation of mmBusinessRule's scope...

It's merely an object containing separate methods used for validating data. The methods themselves look almost identical to the one you mention above, except for a couple lines storing a broken rule in an array.

Later, the broken rules can be accessed by the object that instantiated the business rule object through the ImmBusinessRuleHost interface David was referring to. mmBusinessObject and mmBusinessEvent (the MM class used to loosely-couple multiple objects that need to interface with each other to perform a task... credit card billing, for example) both implement that interface that accesses these bundled rules.

sooo... in a nutshell
1. Almost identical
2. Yes, and yes
3. Depends on how you define straightforward, I guess. We've been using the VFP versions of MM business rules classes for a couple years and found them to be very straightforward. The .NET version is similarly designed.

>
>I do see why one would want to implement an interface to make business objects more accessible, but still, thats fairly trivial and doesn't require a framework.

Well, _nothing_ requires a framework, but I'm hoping we don't hafta go there again after the last couple days!! <g>

Hope that answers your curiosity,
---J