Update from CSLA 2.0.3 to 2.1

gajit posted on Wednesday, November 08, 2006

Hi guys,

I have just bitten the bullet and moved to 2.1 as we will soon be beta testing the new windows application and I wanted to ensure we started with the current technology...

I have a couple of questions...

I encountered the breaking change with regards to the ValidationRules and have implemented all of my existing AddBusinessRules() ..AddRules into their InstanceRules counterparts and it works fine.
But I am a little (ok, a lot) confused about the discussions about a dynamic rule based on different instances of a BO... and that you can have dynamic and non-dynamic rules.

I tried to have both AddBusinessRules() ..AddRule and AddInstanceBusinessRules..AddInstanceRule methods in my BO, but this generate compiler errors (as it calls the former AFTER the latter).

Secondly, my code did not "break" on the Dataportal.Create/Fetch calling semantics... I know I should be happy - but I suspect the 'break' is under certain conditions...

The documentation has my head spinning a little ... what sort of things should I be looking for in terms of compiler messages? should I be getting run-time or compile-time messages?
Does this only apply to objects that might be fetched/created with no criteria passed? If so, what changes should I be making in my BO's?

Any assistance would be appreciated... beta release is due soon and I'd hate to look like Bill Gates launching Windows XP Media Center ....;)

Thanks,
G.

ajj3085 replied on Thursday, November 09, 2006

Well, one thing is that you should try to use type rules when possible over instance rules.

The easiest way to convert your rules is to mark them as static (Shared in vb).

I'm not sure your code will break because of the DP changes if you are always passing a parameter to Fetch or create (even if you ended up passing null or a dummy object).

HTH
Andy

JoeFallon1 replied on Thursday, November 09, 2006

I agree with Andy - you should almost always use the per type rules. The only time you need instance rules is if the rules are different for each instance.

All of my rules are in a separate class as Shared methods.

I also subclassed RuleArgs as MyRuleArgs.

Protected Overrides Sub AddBusinessRules()
      'Acctcode
      ValidationRules.AddRule(AddressOf StringRequired, New MyRuleArgs("Acctcode"))
      ValidationRules.AddRule(AddressOf StringMaxLength, New MaxLengthRuleArgs("Acctcode", 40))
      ValidationRules.AddRule(AddressOf IsValidSyntax, New MyRuleArgs("Acctcode"))
      ValidationRules.AddRule(AddressOf RecordDoesNotExist, New RecordExistsRuleArgs("Acctcode", "acct", "", True), 1)

      'Acctdesc
      ValidationRules.AddRule(AddressOf StringMaxLength, New MaxLengthRuleArgs("Acctdesc", 60))
      ValidationRules.AddRule(AddressOf IsValidSyntax, New MyRuleArgs("Acctdesc"))
    End Sub

Joe

gajit replied on Tuesday, November 14, 2006

Hi guys,

Sorry for the delay in replying - my attention was drawn in another direction for a few days.

I'll have to revisit my validatin rules, but I'm sure when I try to implement them as ValidtionRules.AddRule - I get compile errors - hence moving them to InstanceRules..

But I will clarify this.

Thanks,

gaj.

ajj3085 replied on Tuesday, November 14, 2006

If you do get compile errors, you're better off fixing them than moving to instance rules.

For example, some of my rules didn't use the target parameter from the rule, instead looking directly at the fields / properties. Switching to 2.1 and making the method static of course caused compile errors... but they were easily fixed by using the target parameter and checking it instead.

Spend the time to 'correct' things now, so you won't regret it later.

Andy

Bayu replied on Thursday, November 09, 2006

Hey,

If you are a bit nervous, then perhaps the following is an idea (at least it works for me ;-) ):

- write a BIG NUnit test that does all of the stuff that your app covers (so at least your could go through the CRUD of your critical objects) that works on your old app.

- then test it on your new app ...

I know it's a silly answer in some respects. But in the end it does serve as an objective analysis that checks some of the critical parts (perhaps all, depending on your effort ;-) ). NUnit is really easy to get up-to-speed with, and you can test lots of things: scenario's that you expect to succeed of course, but also scenario's that you expect to fail in a particular way (to check validation rules or exceptions for example).

Just a thought.

Bayu