Using an invalid business object as a parameter?

[hurcane]

We are upgrading a CSLA 5 codebase to CSLA 6, and eventually the current CSLA version. We have a ReadOnlyBase class that currently takes a BusinessBase class as a parameter. The BusinessBase is a configuration class that drives how our product interacts with an ElasticSearch API. The ReadOnlyBase class is a "status" class that tests the functionality of the configuration and sets properties to advise the user which functions actually work and which will cause problems.

In CSLA 5, this worked great. With CSLA 6, the remote data portal is invoking a RevalidatingInterceptor, which is raising an error because the BusinessBase class is not valid. The status class needs to be evaluated on the server because the API calls to ElasticSearch always happen on the server. The client may not have network visibility to the Elasticsearch API.

I could remove the default interceptor, but I'm not sure if that is going to cause problems in standard usage scenarios. I could change the design to not pass the invalid BusinessBase, but that will be introducing a lot of complexity to what is currently straightforward code.

Can anybody offer an opinion on the potential downsides of not having the interceptor in place?

[StefanOssendorf]

Is there a reason why the BusnessBase parameter has to be invalid during usage?
I opted to manage fields explicitly via Get/SetState and avoid them being tracked by the BO.

[rockfordlhotka]

Maybe use warning severity instead of error severity in the rules for this object?

Or override the IsSelfValid or IsValid property of this type to force it to be valid even when it really isn't?

[hurcane]

For eventual save of the business object, we need the rules to be broken. And the status object checks the broken rules collection to know which functions are OK to test and which functions have an incomplete configuration.

My plan for now is to keep the status object, add [RunLocal] to the factory Create method, and delegate the remote functions into a new ReadOnly class that mirrors the editable object's properties. This is a common pattern to have a ReadOnly version of the class because it is more lightweight to send over the network when we don't need the editing capability.