What technique could be used to manage the users request to delete data?

McKay posted on Wednesday, August 12, 2009

For example. The user presses the delete button for a customer business object. First the object must check if the user has permissions and return a message if denied. Secondly the object must run several data checks to determine if the customer owes money or if the customer is owed money and return a message if the condition isn’t satisfactory. If the outcome is satisfactory then the object will be deleted.
Most importantly can this be done from the business object and without throwing Exceptions?
Should I be using a custom command from the commandbase?
The replies to the below post all rely on exceptions being thrown. Does anyone have a technique to control the above logic without throwing exceptions?
http://forums.lhotka.net/forums/thread/35485.aspx
I’d be very interested in your opinions/comments.

JonnyBee replied on Thursday, August 13, 2009

Hi,

Delete button should not be enabled if the user does'nt have permissions to delete the object. (And if the user is allowed to try to delete and does not have permission then SecurityException should thrown)

You could create a CommandObject to do an extra check before calling delete.

But any delete operation could result in errors and I would prefer to just have a Delete that does the check and throws my own execeptions, f.ex   DeleteCustomerOwsMoneyException and DeleteCustomerOwedMoneyException. If you have a remote server you will only make one roundtrip for a Delete rather than one roundtrip for CheckDelete befor next roundtrip that does the Delete (and both may throw exceptions - no matter how good your code is - Database/Communication/Security etc).

Remember: Exceptions must/should always be handled -  how you handle an excpetion (messagebox, statusline or otherwise) is up to the developer that makes the Client app.

Exceptions are not bad - it is actually good coding practice - but you must decide how to handle different types of exceptions.

/jonnybee

RockfordLhotka replied on Thursday, August 13, 2009

In this simple example you might be able to get away without throwing an exception. The reason is that, as described, this particular problem is one where all the checks occur first, and then if they pass the data is changed.

So the object could be constructed with extra property(ies) that can be set to indicate whether the delete operation occurred and if not, why not.

But in the more general case this won't really work, because the checking logic and database update logic get intermixed (at least across different objects). In that case you need the transaction to roll back, and that is triggered by throwing an exception - which is the standard .NET technique for triggering such a rollback.

Even then, if you really wanted to, you could devise your own infrastructure to indicate the need for a rollback and manually handle your transactions. Keeping in mind, of course, that a grandchild object deep in the object graph could trigger the rollback requirement, so your infrastructure would need to flag this case - and all your other could would need to constantly check it to break out of any loops and stop processing and roll back the transaction.

In short, there's a reason .NET favors the use of exceptions for this problem - because inventing your own out-of-band notification scheme would be a lot of work, and would almost certainly complicate the heck out of your code.