views:

424

answers:

2

Hello gurus,

I have an ObjectDataSource in an ASPX page calling CRUD operations from a business logic class. When exceptions occur during those operations, I'd like to inform the users of the errors as well as logging them. But I want a clear separation between my business logic and presentation layer. I know that Selected, Inserted, Updated, Deleted events provide a parameter of type ObjectDataSourceStatusEventArgs which includes a property "Exception" for exceptions occurred.

Are handlers of these events the best place to handle the exceptions for ObjectDataSource or is there a better way? Does the Exception property of the event parameter chain all the exceptions occurred during the operation?

Any comments or suggestions are welcome,

Thanks,

Cullen

A: 

If the methods in the business logic layer are called automatically, I would use these events.

I think the purpose of these events is that: to show an error in some custom way.

But I wouldn't call automatically the methos in my logic layer. Instead, I will call them by code, and return a boolean value indicating if the operation succeed.

Something like this, when inserting/updating a Person:

if (Person.Save(data)) {
  // show OK message
} else {
  // show error message
}

where Person is a BAL class relative to the Person Data Access Layer class.

Hope this help.

eKek0
+1  A: 

When an exception is raised during a CRUD operation performed by your Biz layer object, it should be handled by the Biz object, but partially. This is because you want feedback to reach the Presentation layer (and you also want to log the error). Therefore, you could either:

a. Re-throw the Exception as-is. This will bubble it up to your Presentation layer.

b. Add a name-value data pair to the Data property of the exception and then re-throw it.

c. Wrap the raised exception into a custom exception type and throw that.

This exception will then be bubbled up to your ObjectDataSource and will be available via the ObjectDataSourceStatusEventArgs.Exception property in your Selected/Inserted/Deleted/Updated event handler. You should then check if this property is Null. If not, the ObjectDataSource wraps any Exceptions (yes, plural !) in a TargetInvocationException wrapper, so you will probably need to get at the InnerException.

Then you could modify the UI elements to provide necessary feedback to users that the operation did not complete successfully. Also, you would need to set the ExceptionHandled property to True to prevent the exception bubbling up to the Page level.

As for logging the exception, personally, I would log the error in both layers - Biz logic layer and Presentation layer.

Cerebrus
@Cerebrus: thanks.
Cullen Tsering