CSLA .NET

I've looked through the forums and while other suggestion are valid for relatively static rules, I will be generating dynamic assemblies by compiling the business rules.  These rules will be written in VB.Net or C# by the person maintaining the Rules (possibly the client).  The application requires the changing of the domain of the rules (ie a different company) which may have a completely separate set of rules on the same database structure WITHOUT exiting the application.  In order to apply these new rules, the old ones need to be removed.  Unfortunately the SharedValidationRules mManager Dictionary is not visible to the application UI, so with 2 small changes (which I've made):

File: ValidationRules
    Added:
        Public Shared Sub ClearSharedRules()
            SharedValidationRules.Clear()
        End Sub

File: SharedValidationRules
    Added:
        Public Sub Clear()
            mManagers.Clear()
        End Sub

Usage:
    ValidationRules.ClearSharedRules()

Is is possible to get this included in the next release (or something similar) so I don't have to keep making this change in subsequent revisions?

Thanks,
David Gauerke

David,

Not sure its a good idea for those methods to be public.  The UI shouldn't know how to clear rules; actually I don't think the UI should be able to do that at all.  Your business objects should decide what the rules are... not the UI.

Have you considered loading the dynamically generated classes into a seperate appdomain?  Then you could simply unload the appdomain when the company changes and load up a new one for the new company.

Of course whether or not that works for you depends on the specifics of your situation, which I don't know.

I'd like to request an enhancement also to be able to clear the cache of the business rules.  Our application loads some business rules dynamically because each of our customers can configure which properties of a class are required or not.  The only reason I would like to be able to clear the cache is so that I can reload some different business rules in my Nunit testing.  My Nunit tests do the following (which is not working)

1) Set a string datatype property in the database to required

2) Test that saving the object without specifying the string fails

3) Test that saving the object with the string succeeds

4) Set the string datatype in the database back to not required

5) Set an int datatype in the database to required

6) Test that saving the object with the int succeeds (it does NOT succeed because the string value from the previous test is still required).

I guess for now, I will set a property of each datatype to required at the beginning, then run each test providing all the "other" values for each test.

---

Rob Kraft

If you switch to instance rules, does that help? 

ajj3085:

David,

Not sure its a good idea for those methods to be public.  The UI shouldn't know how to clear rules; actually I don't think the UI should be able to do that at all.  Your business objects should decide what the rules are... not the UI.

Have you considered loading the dynamically generated classes into a seperate appdomain?  Then you could simply unload the appdomain when the company changes and load up a new one for the new company.

Of course whether or not that works for you depends on the specifics of your situation, which I don't know.

I agree wholeheartedly!

The UI should not be able to do this. 

I'm assuming that only one customer's worth of data would be loaded at a time?  If so, the objects should flush the list of rules and re-populate them when the objects are re-populated with a new customer's data.

If the above assumption is not true, then the rules shouldn't be shared, they should be instance rules, set on a per-object basis. 

 

I don't intend to clear the cash in the application; I really just want to be able to do it with my NUnit testing.  Our customers each run their own web server (this is not an App Serv Provider solution); so they will configure their app and NOT want to clear their cache.  However, I want to test my code.  Specifically I want to test my logic that marks a string field required if our customer flags one as required; then another test that marks an int field required if a customer flags an int as required.

I've worked around this by running all the tests at once; so this is not a high priority request.  However, I don't see the risk in exposing the ability to clear this cache - as long as we are writing all the UI code, we wouldn't expose that ability to our customers.

---

Rob Kraft

I've added this to the wish list.

I have serious reservations, because people will use it outside of your narrow testing scenario, and the results will almost certainly be bad - and I'll have to live with the resulting support requests and complaints about bad performance and/or instability. So I need to weigh whether I feel it is worth supporting this valid testing scenario, knowing that I'll have to pay a permanent/continual price in terms of support.

---

Rocky

Would loading the assembly under test (and perhaps part of the test) into a seperate appdomain acomplish what you need? 

I believe that loading it in a separate AppDomain and unloading that AppDomain would work.  I spent a few hours trying to pummel the code into something that would work, but I was not successful.  I may try it again in the future when I have more time.  Thanks for all the feedback.

---

Rob Kraft

---

Rocky

Why not just add a ClearRuleCache() method to your internal testing version of csla so that you can use that in your tests?

Andrés

Are you using a rules engine to compile the rules?