Hi all,
I have the following situation:
There is a simple object graph like this:
Having the above object graph I want to add a business rule that sounds like this: "if the RealEstate.Status == 1 then Address.PostCode is required".
Also I would like to add this business rule to the child (i.e. Address) business rules collection not to the parent (i.e. RealEstate) business rules collection.
Can this be achieved with CSLA?
Thanks in advance!
Hi,
Do not model your Business Objects as they are represented in the database model.
Your BO'sshould be modeled from a use case perspective and hierarcies should be flattened when you have 1:1 relationships. This will make it MUCH easier to create rules and increase mainainability.
Hi Jonny,
Thank you for your advice. I totally agree to that.
In the previous post I didn't choose a good example. I am going to offer a new one modeled by a Use Case.
The Use Case sound like this:
I have a form which edits the Company business object. The form contains fields for Company basic type properties (Name, RegistrationNumber, IsActive) plus a grid that contains the Company Locations. The grid allows you to add, edit, delete a Location business object.
My Use Case has a parent business object (Company) that contains a list of children business objects (Location).
The question is if I can have a business rule like this: if Company.IsActive is true then foreach Location in Locations the PostCode is required.
Thank you.
Hi,
Interesting problem with inter-object dependencies - and a new possible solution in csla4:
1: Use RuleSets and expose a method to set active ruleset and call CheckRules when the property for IsActive is changed. Will work nice if you have only one or 2 dependencies but may be harder to use if yu have many rules and more dependencies. Ie: Have one ruleset for "Active" and one ruleset for "Passive".
2. Have rules that walk the "Parent" tree and read the IsActive to dermine validation. This is also painful in that you probably must add a custom interface and method on your BOs to call CheckRules on your children, custom interface/methods on the parent to define the IsActive property and custom code when IsValid is changed to to propagate CheckRules to the children. Also painful that the rules will not work properly on new objects until the parent property has been set.
We have done 2) in pojects that target pre Csla 4 and it is a pain. Especially handling that must occur when Parent is set (and also trigger a new CheckRules).
I'd love to hear if anyone has tried RuleSets.
Hi,
Thank you, Jonny, once again for your answer.
I started to dig in the csla 4 last week, in conclusion I don't know its power yet.
In the first ebook Using Csla 4 when Rocky speaks about Business, Validation and Authorization Rules he enumerates some types of rules. The second type is "Validation of values across multiple objects in an object graph". I am wondering if my problem is contained in this type of rule!
Anyway one thing is truly certain: I have to study more about the Business Rule Engine in csla 4.
Thank you.
I would continue your research, as it does sound like that would be the way to go if you're on Csla 4.
If you're on an earlier version, there are a few choices.
One is for the parent to implement the rule, and check all of its children. Fairly easy using Linq. The problem is you need to manually run the rule whenever a child changes, and there's no easy way to provide indication to the user as to what's wrong.
The second approrach would have a rule in the child ask its parent (the collection) for the root BO. The rule would return true (valid) if the state on the BO isn't one which requires the postal code, or it could call the CommonRules.StringRequired rule to continue validation. In this way, each postal code in the grid would have an error indicator automatically show.
The choice is up to you, and how you want to present the validation results to the user.
HTH
Andy
Hi Andy,
Thank you for your suggestions.They are useful.
I am using indeed an earlier version of csla. In this context, from your suggestions I would choose the second one due to the fact that an error indicator can be shown automatically on the PostCode field. The rule sits, indeed, on the child (Location in this case) and is check by the Child when the Location.PostCode property changes and is checked by the parent (i.e. Company) when the Company.State property is changing. Please, correct me if I'm wrong!
The scenario I presented (i.e. Company having a list of Locations) can be extended. Maybe I'm wrong but I would venture to say that it would be good to have the possibility to implement business rules between objects in an object graph without breaking the object design principles.
Thank you for your time, guys, and for your useful suggestions.
Muntean
Copyright (c) Marimer LLC