Handling Errors wrt ObjectDataSource

Discussion in 'ASP .Net' started by Kevin Frey, Nov 7, 2006.

  1. Kevin Frey

    Kevin Frey Guest

    One of my chief criticisms of validators in an ASP.NET page is that they can
    result in a developer re-implementing much of the "business logic" of a
    transaction at the page level.

    Assuming we have an object that implements business logic, and that object
    is utilised via an ObjectDataSource, I wish to enquire what the correct
    method is for handling errors from the business logic object.

    For example, there are some circumstances where a transaction cannot be
    completed due to a validation error. But for the sake of this discussion,
    and to remove any potential for using a "Validator" in a pre-validation
    sense, let's assume the "validation error" is due to a
    transaction-time-determined consistency-related operation such as an
    organisation exceeding their credit limit at the time of placing an order.
    Clearly in a multi-user system such a test can only be performed when the
    operation is being committed to the database, because otherwise it is
    [potentially] subject to violation.

    So, with a view to "best practices implementation", how should my business
    logic object report such an error? Throw an exception?

    And how should my page react to such an exception? Should I be hooking event
    handlers onto the Inserted, Deleted (etc) events of ObjectDataSource and
    then interrogating the ObjectDataSourceStatusEventArgs object for the
    presence of an Exception?

    If there is an exception, what would a typical course of action be? Would it
    be feasible to somehow inject a message into a ValidationSummary control?

    Many thanks

    Kevin
    Kevin Frey, Nov 7, 2006
    #1
    1. Advertising

  2. If I understand your rather wordy hypothesis, it seems you are questioning
    whether it is feasible to propagate a business - logic failed transaction
    condition up to the UI where page-level validation is being used.

    I guess it really boils down to whether or not the page-level field
    validators are really concerned with a business - logic condition, and
    normally, they are not.

    So what I'd be looking at is simply an elegant way to inform the user that
    although there was nothing wrong with their inputs, the transaction failed
    and show them the reason if appropriate. How you do this is of course
    entirely up to you to determine. A simple message on a label should suffice.
    Peter

    --
    Co-founder, Eggheadcafe.com developer portal:
    http://www.eggheadcafe.com
    UnBlog:
    http://petesbloggerama.blogspot.com




    "Kevin Frey" wrote:

    > One of my chief criticisms of validators in an ASP.NET page is that they can
    > result in a developer re-implementing much of the "business logic" of a
    > transaction at the page level.
    >
    > Assuming we have an object that implements business logic, and that object
    > is utilised via an ObjectDataSource, I wish to enquire what the correct
    > method is for handling errors from the business logic object.
    >
    > For example, there are some circumstances where a transaction cannot be
    > completed due to a validation error. But for the sake of this discussion,
    > and to remove any potential for using a "Validator" in a pre-validation
    > sense, let's assume the "validation error" is due to a
    > transaction-time-determined consistency-related operation such as an
    > organisation exceeding their credit limit at the time of placing an order.
    > Clearly in a multi-user system such a test can only be performed when the
    > operation is being committed to the database, because otherwise it is
    > [potentially] subject to violation.
    >
    > So, with a view to "best practices implementation", how should my business
    > logic object report such an error? Throw an exception?
    >
    > And how should my page react to such an exception? Should I be hooking event
    > handlers onto the Inserted, Deleted (etc) events of ObjectDataSource and
    > then interrogating the ObjectDataSourceStatusEventArgs object for the
    > presence of an Exception?
    >
    > If there is an exception, what would a typical course of action be? Would it
    > be feasible to somehow inject a message into a ValidationSummary control?
    >
    > Many thanks
    >
    > Kevin
    >
    >
    >
    >
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=, Nov 8, 2006
    #2
    1. Advertising

  3. Kevin Frey

    Kevin Frey Guest

    Forgive me for my wordiness. I wanted to make sure someone didn't try
    subvert the problem by simply "suggesting" I use a validator - when clearly
    a validator cannot be used in some circumstances.

    As an aside, I don't necessarily agree with your assertion that page-level
    field validators are not really concerned with "business logic", except
    those validators that are concerned merely with "domain-specific" type
    validation (eg. ensuring a date is formatted correctly or something).
    Everything else starts to become associated with the "contractual
    requirements" of the business logic interface (eg. value X must be between 1
    and 10, etc), and viewed in this manner it is entirely possible to implement
    a large number of validators under the guise of meeting the contractual
    requirements of the interface (ie. to ensure that I give it the right inputs
    so it doesn't blow up).

    > So what I'd be looking at is simply an elegant way to inform the user that
    > although there was nothing wrong with their inputs, the transaction failed
    > and show them the reason if appropriate. How you do this is of course
    > entirely up to you to determine. A simple message on a label should
    > suffice.


    Unfortunately, you've simply reiterated my question and told me to solve it
    myself. Hence your answer is really no answer at all (and I say that without
    malice, because I appreciate you replying nonetheless). Yes, I understand I
    could use a label to issue an error message. I'm looking for "best
    practices" methodologies for handling these sorts of problems. Are you
    suggesting this is good as it is going to get?

    Kevin

    "Peter Bromberg [C# MVP]" <> wrote in message
    news:D...
    > If I understand your rather wordy hypothesis, it seems you are questioning
    > whether it is feasible to propagate a business - logic failed transaction
    > condition up to the UI where page-level validation is being used.
    >
    > I guess it really boils down to whether or not the page-level field
    > validators are really concerned with a business - logic condition, and
    > normally, they are not.
    >
    > So what I'd be looking at is simply an elegant way to inform the user that
    > although there was nothing wrong with their inputs, the transaction failed
    > and show them the reason if appropriate. How you do this is of course
    > entirely up to you to determine. A simple message on a label should
    > suffice.
    > Peter
    >
    > --
    > Co-founder, Eggheadcafe.com developer portal:
    > http://www.eggheadcafe.com
    > UnBlog:
    > http://petesbloggerama.blogspot.com
    >
    >
    >
    >
    > "Kevin Frey" wrote:
    >
    >> One of my chief criticisms of validators in an ASP.NET page is that they
    >> can
    >> result in a developer re-implementing much of the "business logic" of a
    >> transaction at the page level.
    >>
    >> Assuming we have an object that implements business logic, and that
    >> object
    >> is utilised via an ObjectDataSource, I wish to enquire what the correct
    >> method is for handling errors from the business logic object.
    >>
    >> For example, there are some circumstances where a transaction cannot be
    >> completed due to a validation error. But for the sake of this discussion,
    >> and to remove any potential for using a "Validator" in a pre-validation
    >> sense, let's assume the "validation error" is due to a
    >> transaction-time-determined consistency-related operation such as an
    >> organisation exceeding their credit limit at the time of placing an
    >> order.
    >> Clearly in a multi-user system such a test can only be performed when the
    >> operation is being committed to the database, because otherwise it is
    >> [potentially] subject to violation.
    >>
    >> So, with a view to "best practices implementation", how should my
    >> business
    >> logic object report such an error? Throw an exception?
    >>
    >> And how should my page react to such an exception? Should I be hooking
    >> event
    >> handlers onto the Inserted, Deleted (etc) events of ObjectDataSource and
    >> then interrogating the ObjectDataSourceStatusEventArgs object for the
    >> presence of an Exception?
    >>
    >> If there is an exception, what would a typical course of action be? Would
    >> it
    >> be feasible to somehow inject a message into a ValidationSummary control?
    >>
    >> Many thanks
    >>
    >> Kevin
    >>
    >>
    >>
    >>
    Kevin Frey, Nov 8, 2006
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Goldin

    Errors, errors, errors

    Mark Goldin, Jan 17, 2004, in forum: ASP .Net
    Replies:
    2
    Views:
    916
    Mark Goldin
    Jan 17, 2004
  2. Kalpesh
    Replies:
    0
    Views:
    308
    Kalpesh
    Feb 2, 2006
  3. Kalpesh
    Replies:
    0
    Views:
    310
    Kalpesh
    Feb 2, 2006
  4. David Thielen

    ObjectDataSource method as another ObjectDataSource

    David Thielen, Mar 21, 2006, in forum: ASP .Net Web Controls
    Replies:
    3
    Views:
    228
    Steven Cheng[MSFT]
    Mar 23, 2006
  5. Mythran
    Replies:
    3
    Views:
    1,216
    Allen Chen [MSFT]
    Aug 12, 2009
Loading...

Share This Page