Blazor - Rules that require data validation

[Blarm1959]

Hopefully I can explain this in a meaningful way!
I have been looking at the BlazorExample solution
There doesn't seem to be an example Rule showing what happens when a data lookup is required to validate the data
For example if the Person BO had a DepartmentID column that references the Department table in the database
On the Blazor UI it could obtain a list of departments and populate a dropdown for the user to choose a department
When a department was chosen the DepartmentID field in the BO would be set. At this stage there could be a ValidDepartment Rule that checked that the department existed in the List used to populate the Department dropdown OR it could just assume that because the Department had been selected from the dropdown then it existed (which of those is correct is not the point of this post). In either case there is no need to go back to the server /database to get the latest Department list if you want the UI to be as reactive as possible
When the Person BO is then saved back at the Blazor server it would need to run the ValidDepartment Rule to validate against the actual Department data in the database in case the chosen Department had been deleted or made invalid by another user whilst this user had been editing the Person (i.e. the server side Rule would always use live data as data from the client shouldn't be assumed to be valid)
I'm not sure how the Rule could be written so that it operated differently under Blazor Client vs Blazor Server or perhaps I should be thinking about this another way

[Chicagoan2016]

If I understand your question correctly, your ValidDepartment rule will run a command object (or something similar) and if the rule returns 'false' it will make the object invalid and hence you can't save the object.

[Blarm1959]

Yes Chicagoan2016, that's what should happen
Currently I use angular for the UI and BreezeJS as a local temporary database for each form.
All the rules from the BOs are duplicated in JS in the UI.
I was hoping that Blazor may allow me to just have the Rules in the CSLA BO
It is wasteful from a performance point of view to validate a value selected from a dropdown by going back to the server/database as the chances that the dropdown data will have changed is very minimal.
However the Rule will need to check the actual data when doing a Save so as to catch those minimal cases where the data has been changed by someone else and to make sure the data is valid

[JacoJordaan]

I can think of 2 ways of doing this.

1. Run a separate rule to check the database before doing the save. This will need to only run before saving.
2. In your rule you can check for Csla.ApplicationContext.ExecutionLocation to determine where the rule is running and then have different behavior based on the execution location.

[Blarm1959]

Thanks, I didn't know there was a Csla.ApplicationContext.ExecutionLocation
I think that will do nicely
I'll check that out to see what its value are

[TheCakeMonster]

Yes, I think the switch based on location is your best bet.

There is a RunModes enum that you can use to define where your rule can run and I wondered if you could use that. However, it doesn't cater for the specific scenario you want - you can stop a rule running on the server, but you can't stop it running on the client.

One thing you could do is cache the list against which you are running on the client, so that the rule still runs, but does so against cached data. Then do a lookup against the database on the server. However, unless you are using a database transaction and locking the table against which you are testing, there is still a chance that the database changes between when you run the rule and when you apply the change to the database even if you hit the database as part of the server-side save operation.

I suppose you have to bear in mind that you are getting into the realm of diminishing returns. How hard you should work to completely resolve the issue depends on the scenario.

The most agile of approaches might be to try ignoring the problem and see if it happens in production. Fix it only if it really happens, when you have more visibility of real world usage.

[Blarm1959]

Thanks @TheCakeMonster

I've been using CSLA for many years and did a fair amount of work with @tfreitasleal on producing the CSLAGenFork VB code for 4.5 and fixing a few C# problems
Never had to distinguish between client and server as far as CSLA is concerned as started in 2006 with WinForms and then started using ASP.Net WebForms and then Angular for the UI and CSLA 4.6/WebAPI for the middle tier relying on SQL Server for transactions and referential integrity
In a trade off between giving a user a good UI experience that is responsive I have (rightly or wrongly) decided that using the data locally, even if it may be in rare occurrences a bit out of date, is better than repeatedly puling the data from the server/database as long as on the actual save the information is checked against the BO rules and the database does it's thing within a transaction.
I did look at caching the lists, but as I had never realised there was a way of checking between code running at client/server I saw that as the same problem with trying to have code that distinguished between client/server in the rule

You learn something new every day and maybe I should have read the CSLA books, etc. a bit more thoroughly!

[Blarm1959]

Can any one give me a code snippet that shows how to use ExecutionLocation in a Rule in a Blazor app
For example what would replace the XXXXXXXXXXXX in the code below to skip the check of the letter Z

namespace BlazorExample.Shared
{
public class NoZAllowed : BusinessRule
{
public NoZAllowed(Csla.Core.IPropertyInfo primaryProperty)
: base(primaryProperty)
{ }

protected override void Execute(IRuleContext context)
{

  XXXXXXXXXXXX

  var text = (string)ReadProperty(context.Target, PrimaryProperty);
  if (text.ToLower().Contains("z"))
    context.AddErrorResult("No letter Z allowed");
}

}
}

[TheCakeMonster]

It would be one of these two:

if (context.ApplicationContext.ExecutionLocation != ApplicationContext.ExecutionLocations.Server) return;

or

if (context.ApplicationContext.ExecutionLocation != ApplicationContext.ExecutionLocations.Server)
{
  context.AddSuccessResult(false);
  return;
}

I can't remember if you need to set a success result before returning, or if success is the default assumption if you do nothing. Try both and see.

For completeness, I should point out that there are two execution locations exposed by ApplicationContext. One of them is the logical location and the one I have used is the physical location. Code can run logically server-side but physically in-process if you are using the local data portal proxy, rather than a remote data portal.

[michaelcsikos]

Running the rule on the server still doesn't guarantee that in the millisecond after the rule completes but before the save to the database someone else hasn't deleted it. If the database is relational it will enforce the foreign key integrity anyway, so this is the ultimate validation check for something which ultimately is extremely unlikely to happen.

In my opinion, once the object is in the process of being saved on the server the assumption should be that the data is valid, and let the database handle FKs, etc. If a business rule fails on the server, it's not a very nice user experience either, because it looked like everything was fine when they clicked Save. So, if really you want to validate the existence of the department, you should run it async on the client as well.

[rockfordlhotka]

This is a good observation. At the end of the day, these rules are just to provide a nice user experience in the 99% case. It is always possible that the actual database operation will fail during insert/update, so that scenario needs to be handled. These rules usually prevent that case and give the user a better example, but it is impossible for them to be 100% effective.

[Chicagoan2016]

It's a very interesting scenario, almost every application I have worked on, has drop-downs populated from 'lookup' tables and those tables stay pretty 'constant'.

[rockfordlhotka]

That's why I say that this type of rule works 99% (or more) of the time - giving the user a good experience.

We just shouldn't forget that it is possible to have a multi-user concurrency collision, and the app shouldn't fail in that case.

[Blarm1959]

To give users a good UI experience that is responsive I have, over many years, decided that using the data locally from the dropdowns/selection/etc is good enough to use for validation on the client, even if it may be in rare occurrences a bit out of date. This is better than repeatedly pulling the data from the server/database.
On the actual update/create the information is fully checked against the BO rules on the server and then the database does it's thing using a transaction/referential integrity/multi-user concurrency collision/etc.
If there is an error from the database transaction then quite often the message given to the user can be difficult for them to understand,. But even in system where there are many users this type of error has been extremely rare and so I don't think it necessary to try and translate the database errors into something more meaningful to the end user. It's my experience that the user will receive the 'strange' error on the form and then try saving again which should then give them a meaningful BO validation error this time.
I accept that this could be a bit of a cycle where under some very very extremely unlikely conditions the data has again changed between BO rules checking and database transaction to cause database errors, but it will be so rare that I'm happy to ignore that
I think that's the best I can do and as long as the data in the database is consistent with what is expected then I'm happy