tolga wrote:
I really like the the new validation and authorization model with the overridable virtual methods on partial classes...
Though, specifically in the case of autorization, this raises a design question:
When an unauthorised field is returned as a null, how does the calling scope know whether that is meant to be null or is null because of lack of privs?
The idea is this:
is the caller allowed to see the REAL value? If not, return void. Void means null, which leads to the default value for that field's type, e.g. 0 for ints and null or "" for strings.
Throwing an exception in the overriden authorization method will cause a maintenance nightmare in the GUI code because any databinding operations will fail because they will receive exceptions when accessing fields the user is not authorised to view.
It's almost like the ideal model would need to be aware of what fields are not readable or updatable and retrieve and update only those fields.
I am curious to find out how people are solving this design challenge...
Thanks
I think the main solution is found in the answer on this question:
if John isn't allowed to see customer.CreditCardNo, what should the value of ccn be in the following line of code executed by the user 'John':
string ccn = myCustomer.CreditCardNo;
Btw, the field still has the real value. So if the field returns null because the user isn't allowed to see the value, it doesn't mean the field becomes null.
You could also remove the field from the UI btw, based on the fact if the user is allowed to see the field.
