I'm looking for an easy and consistent way for a BO to notify the UI that an Add, Delete, Save, or Undo has been canceled. Having corresponding “Canceled” events to these methods would be one solution.  The event arguments would be similar to the existing After events except that a “message” item would need to be added to the Before and Canceled events to allow the developer to include a reason the method was canceled.

Currently I'm including logic in the form that I feel should really be in the BO because there is nothing in the framework (at least I haven't found it) to communicate to the UI that a method was cancelled in the BO and why. There may be a better way of doing this in the current framework that I haven’t thought of, and if so, I’m open to suggestions.

One other thing I noticed while thinking about this is that the BO Save methods are overridable while the Delete methods are not.  I’d like to see them marked overridable to allow the developer to extend them if necessary.  

-Larry

-Larry

Hi Ben,

The reason for the request was to handle the following type of situation.

·     Business Rule: You cannot delete a customer that has related orders.

·     Business rule is enforced by a foreign key relationship in the database

·     Using the SF maintenance form if you try to delete a customer with related order records you get an ugly exception error. While it might be possible to capture the exception and display a friendlier message you shouldn’t be relying on exceptions to enforce your business rules and therefore some additional logic is required.

·     Create a public method on the customer BO to check for related records.

·     Use the maintenance form’s BeforeDelete event to access the public method on the BO and if there are related records, generate a friendly message to the user and cancel the delete.

While using the form's BeforeDelete event works, I felt that checking for related records and canceling the delete is a business rule that should be handled by the business object and not the form. The problem is that there is no facility within the framework for the BO to inform the UI that it canceled the delete and provide a reason.  Currently if you use the BO's BeforeDelete event and cancel the delete within the BO, the records aren’t deleted and the only information accessible to the UI is that zero records were deleted (I didn’t actually check to see if DeleteCurrentRow() returns 0 if the delete is canceled but I assume that is what happens).  There may be multiple business rules that prevent a record from being deleted, so just informing the user that nothing was deleted is not very informative.

Although I can certainly provide the functionality the user expects using SF as is, I’ve always tried to keep the UI as dumb as possible and place all the smarts in the BO. I know I’m probably being overly picky but it comes from reading too many books like Expert One-On-One Visual Basic .NET Business Objects.

-Larry

And yes, we cram everything we can into the business objects... there's just no reason to have the UI contain logic like that, so you are definitely on the right track.

-Larry