Csla 6.2.2 BypassPropertyChecks usage

[Brad-IMS]

In the Csla 6.2.2 Samples, PersonEdit class in 'BlazorExample', Insert and Update, in addition to Fetch, specify BypassPropertyChecks. Is this an error, or is this because the property checks are now done elsewhere?

[TheCakeMonster]

It is fairly normal to use BypassPropertyChecks to avoid doing multiple rule executions during data access operations. It is more efficient to do the validation only once, in the situation that any rules are dependent upon multiple properties.

If you want to, you can optionally call CheckRules after the properties have been loaded to update the status of all of the validation rules. That runs all of the rules at once, only once.

Example: Rule1 is dependent upon Property1 and Property2. If you do not use BypassPropertyChecks then Rule1 runs twice, once as Property1 is set and one as Property2 is set. Using BypassPropertyChecks and CheckRules ensures that Rule1 runs only once.

There are two schools of thought as to whether to validate during a fetch operation. Generally, Rocky writes the code samples based on the belief that the data could not have made it into the database if the data were invalid. I tend to run the rules after a fetch anyway, to cater for the system changing over time - new rules might be added to the system after the data was first written to the database.

[Brad-IMS]

I am migrating from a CSLA 4.5 environment to 6.2.2. In that previous environment I followed the suggested setup and used BypassPropertyChecks only on Read operations. So, I was surprised to see BypassPropertyChecks on Insert and Update in the sample. Therefore, my question: was this an oversight or was there a valid reason for doing so? If you create a system for policing properties, I would think you would not want your examples to suggest not using it.

[jonnybee]

You should also keep in mind that BypassPropertyChecks will also bypass authz rules that could possibly deny read of property value.

So use BypassPropertyCheks to make sure you can read all the properties by using the property getter (=> GetProperty)

[Brad-IMS]

Let me rephrase my question. If I have business rules or authorization rules, and I want my database to be error-free, should I be using BypassPropertyChecks on Insert and Update operations? If not, why would the sample app, which people refer to for guidance, promote doing so?

[kcabral817]

I would not bypassPropertyChecks on insert and updates. I use it to bypass on reads only when I'm formatting my objects from the ORM.

[Brad-IMS]

I would not BypassPropertyChecks on inserts or updates either, but since Rocky's sample app is doing so, I am asking is there a specific reason for doing so in Csla 6.2.2 or is this an error.

[jonnybee]

To make sure that your code can call BO.Property and get the actual value in the Insert/Update method.

    public static readonly PropertyInfo<int> IdProperty = RegisterProperty<int>(nameof(Id));
    public int Id
    {
      get { return GetProperty(IdProperty); }
      set { SetProperty(IdProperty, value); }
    }

Will eventually end up here:

    protected P GetProperty<P>(PropertyInfo<P> propertyInfo, Security.NoAccessBehavior noAccess)
    {
      P result = default(P);
      if (_bypassPropertyChecks || CanReadProperty(propertyInfo, noAccess == Csla.Security.NoAccessBehavior.ThrowException))
        result = ReadProperty<P>(propertyInfo);
      else
        result = propertyInfo.DefaultValue;
      return result;
    }

So if the user does not have read permission you may get default value for the type rather than the actual value.