Hello,
I am using CSLA 4 and I need to create an authorization rule (or at least a rule that throws an exception if it does not pass) that would not allow setting a property if the value being set is not part of a specific domain (Ex. list).
Ex. There is an integer that should be part of a list that was fetched from the database.
The problem is that when the authorization rule executes it does not know the future value that will be set to the property.
Note: Validation Rules are not an option because by the time they execute the value is set and does not throw exceptions.
What would be an elegant way to implement this without breaking the CSLA standards?
Thanks,
Lazaro
You need to think about the consequences of such an action. This is less about "CSLA standards" than it is about what data binding expects.
Data binding (generally speaking) doesn't like exceptions to occur in property setters. So if you go down this road, you may find that extra work is required in the UI to work around the exception, or the fact that the poor user is locked into that field and can't get out without using Task Manager to stop the process (depending on the UI technology).
Additionally, data binding (generally speaking) doesn't like to put a value into a property and to then have the value not be there, or to be different - at least not without a PropertyChanged event reporting that the value has been changed (reverted).
And that is, I think, the answer. Create a business rule (not validation) that reverts the property to its previous value. That requires tracking the previous value, but will "prevent" it from being set to an invalid value without violating the expectations of data binding.
Copyright (c) Marimer LLC