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]" <pb*******@yahoo.nospammin.comwrote in message
news:D8**********************************@microsof t.com...
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
