Validating objects that a Csla BO contains

NoviceCoder posted on Wednesday, January 17, 2007

Hi,

I was wondering if the Csla framework made it possible for BOs (classes that inherint from

BusinessBase<T>) to validate objects contained within them, for example

I have a Customer class that contains an AddressInfo object. This object simply contains fields and properties (address, city, region etc.) so that it can be used by many different classes, Customer being one of them.

Now, as far as I know, validating properties can only be done on the BO itself. Same thing I think with authorization.

Is there a way to validate/authorize objects contained within the framework's business objects?

In addition, are there there going to be any issues with databinding those composed objects?

Thanks,

Ben

ajj3085 replied on Wednesday, January 17, 2007

Well you'd have an Address object (AddressInfo would usually be for display purposes only) which has its own business and authorization rules.  The parent BO would override its IsDirty and IsValid properties so that it takes the Address' IsDirty and IsValid states into consideration.

HTH
Andy

JoeFallon1 replied on Wednesday, January 17, 2007

In CSLA 1.x a user contributed some code to allow a given BO to validate all contained BOs and their contained BOs and on down the chain.

I posted a version of this code for CSLA 2.x a few months back.

The idea is that this allows you to do a few things:

1. Skip the override for IsDirty.

2. Get a list of all broken rules for a top level BO and all its contained BOs.

Search the forum for sample code.

It may be simpler to just do the overrides for now though.

Joe

 

NoviceCoder replied on Wednesday, January 17, 2007

I see.

So, my Address class has to be a BO too. Well, that's a bit of an overkill for such a simple class.

I might have lots of classes like this in my app, so turning each and every one of them into a BO might have some overhead to the application.

Wouldn't it be much simpler if  ValidationRules class defined an overload for AddRule() that accepted, in addition, an object to perform the validations upon? I saw the code for the ValidationRules class and I think that the target is just a System.Object instance, not a Csla framework BO, making any object viable candidate for validation. So that means that the ValidationRules class would simply maintain a collection of objects to validate and their corresponding properties, isn't that so? In addition, this way, the BO gets a fine grained control as to which properties to validate and every BO can implement it as they see fit.

Ben

ajj3085 replied on Thursday, January 18, 2007

NoviceCoder:

So, my Address class has to be a BO too. Well, that's a bit of an overkill for such a simple class.

Why would you say that?  It has its own set of behaviors.  It fulfils a purpose in your use case.  It might be a simple class, but that doesn't disqualify it as a BO.  Especially since it probably should support remoting, n-level undo, etc.

NoviceCoder:

I might have lots of classes like this in my app, so turning each and every one of them into a BO might have some overhead to the application.

Yes, you likely will have a lot of classes.  Likely a few per use case.  That's expected.  Its not overhead, because its necessary to properly build your application. 

NoviceCoder:

Wouldn't it be much simpler if  ValidationRules class defined an overload for AddRule() that accepted, in addition, an object to perform the validations upon?

It would be simplier, but you're violating one of the most basic OO principals, that each object is soley responsible for its own state, and that other objects may not directly change its state.  In other words, its a very bad design.  That would be true even if Csla was not in the mix at all.

NoviceCoder:

I saw the code for the ValidationRules class and I think that the target is just a System.Object instance, not a Csla framework BO, making any object viable candidate for validation. So that means that the ValidationRules class would simply maintain a collection of objects to validate and their corresponding properties, isn't that so? In addition, this way, the BO gets a fine grained control as to which properties to validate and every BO can implement it as they see fit.

The eventual rule method that runs is typically defined in the BO itself.  There are some common methods to facilitate reuse however.

The problem is you've now just made the ValidationRules class more complex.  Not only does it need to track the broken rules, it has to track the objects for which to check rules.  What happens when the object VR is tracking goes out of scope?  What happens as the object is remoted?  You've violated the Single responsiblity principal, and VR will now become much more difficult to maintain. 

And that's really the whole point of proper OO design and BO design; to make software more maintainable.