It has been a while, done lurking, and I'm jumping from 1.53 to 3.0.2. Thankfully, there's no legacy code to worry about, but I cannot use .NET 3.0 features at all:
PITA.Add(incompletImplementation.(this));
I have in my BO a use case where if a rule (manufacturing control limit) is broken, the worker needs to obtain an OK from an authorized person before they can continue. The use case calls for the PC to effectively lock until the event is dispositioned. Given that the current BO will be running using an unauthorized identity, the only thing I've come up with is a public method on my BO that will accept the response from a UI box of my design:
public void AcceptDisposition(Guid _boID, int val){
if(this.ID == _boolID)
{ //goahead and process
this.Val = val;}
}// or something
This would allow the change to be fed to the BO instance in the form and set/fire property changed events.
For example: an authorization is needed, my InputBox pops, user with proper authorization logs in, and feeds an "OK" and value to the BO via that method. I think that would remove any responsibility from my BO and it would only need to know the BO ID matches the one that it is changing and doesn't need to reload the BO or hit the db. It does seem to make the UI developer more responsible than she should be. IDK
Does this sound to hacky/hokey? If you have a suggestion, let me know. Nothing similar penetrated my allergy med shield as the same use case in the archives.
Thanks
_E
Would it be possible to add a few more rules? One would be that the OK property is required (and must be true) once the control limit has been reached (this would allow setting the control limit, but then it places the object in an invalid state once it has been set by always checking the OK property rule against the _originalLimit value). When the object is saved with the violating limit - the refreshed / updated object now has the violating limit as its _originalLimit value and the rule is broken. The second rule would be that the OK property can only be changed when the user belongs to the specific role you need. (You’ll need to keep a “copy” of the original values so you can check if they have been changed or not – before checking the role)
if (_ok != _originalOK && !Csla.ApplicationContext.User.IsInRole("MyRoleHere"))
{
e.Description = "Only MyRoleHere personnel can change Approval.";
return false;
}
else
{
return true;
}
Of course just setting the AllowWrite property covers the second rule where you would only need the first one. I know this gets a little strange – it is hard to tell sometimes where to draw the line between “Authorization” and “Validation”; however, I think this might work for you. Only the person in the correct role can make the change such that the object is in a valid state; therefore, only they can save / update it!
Your situation may be a little more complicated, but it should just be a matter of creating rules for properties that break when the OK property is false and the violating limit is reached (and checked against the current value) so that they cannot change properties you do not want them to until the OK has been set by the appropriate authority.
Ken
KKoteles:
Your situation may be a little more complicated, but it should just be a matter of creating rules for properties that break when the OK property is false and the violating limit is reached (and checked against the current value) so that they cannot change properties you do not want them to until the OK has been set by the appropriate authority.
Thanks, Ken, I think that's pretty close to what they need. I hadn't started combining rules yet b/c the users are still defining this case. I suppose there could be a child collection attached where the authorization is held (for traceability). I do know they wanted this type of information elsewhere.
I could expand this into a problem/fix collection for the process and/or part. It would allow them to see more trends that way on problem parts and also gather data about successful resolutions -- something they hadn't thought about.
Thanks for the suggestion. I'll ponder while they are finishing up the requirement. Good thing is this one thing will cascade throuhout the application. I think it sounds very beneficial in stabilizing the process.
_E
Copyright (c) Marimer LLC