Forms Validation - Reusing Business Logic

[jehugaleahsa]

Hello:

Is it me, or is handling the Validating event for every control on a
form extremely annoying? It is especially annoying when my business
logic repeats most of the validation. Some things you can handle in
the business logic. But other things, like ensuring a textbox
represents a number or null, requires a developer's intervention.

I am asking whether or not there is an easier way of doing validation
for data bound controls.

Really, I am asking how other Forms developer perform validation.

 

[Anthony Jones]

Hello:

Is it me, or is handling the Validating event for every control on a
form extremely annoying? It is especially annoying when my business
logic repeats most of the validation. Some things you can handle in
the business logic. But other things, like ensuring a textbox
represents a number or null, requires a developer's intervention.

I am asking whether or not there is an easier way of doing validation
for data bound controls.

Really, I am asking how other Forms developer perform validation.

One approach is to split the business object down the middle. Instead of a
three layer approach:-

UI -> Business -> Persistence

Use:

UI -> BusinessClient -> BusinessServer -> Persistence.

The BusinessClient runs on the same tier that the UI does, IOW its a library
included in the UI app. Hence it can provide rapid feedback to the UI which
would be bound more tightly. You just need to define interfaces that are
understood by the UI and allow the BusinessClient to describe things such as
simple rule breaches.

I might just add though that the example of "must be a number" isn't a good
one. You would expect the UI developer to use a control which simply didn't
allow incorrect input of that nature in the first place. However missing
data would be exactly the sort of thing you would want the BusinessClient to
inform the UI of.

The BusinessServer half would do the things that are best done close to the
data tier.

The BusinessClient and BusinessServer are considered to be the same class in
that each has an intimate understanding of the internal workings of the
other. In a fat client you can have a single class and simply serialise the
object state between tiers. In Web apps I create the BusinessClient is in
JavaScript, BusinessServer is in C# and internal state is held as XML.

 

[jehugaleahsa]

One approach is to split the business object down the middle.   Insteadof a
three layer approach:-

UI -> Business -> Persistence

Use:

UI -> BusinessClient -> BusinessServer -> Persistence.

The BusinessClient runs on the same tier that the UI does, IOW its a library
included in the UI app.  Hence it can provide rapid feedback to the UI which
would be bound more tightly.  You just need to define interfaces that are
understood by the UI and allow the BusinessClient to describe things suchas
simple rule breaches.

I might just add though that the example of "must be a number" isn't a good
one.  You would expect the UI developer to use a control which simply didn't
allow incorrect input of that nature in the first place.  However missing
data would be exactly the sort of thing you would want the BusinessClientto
inform the UI of.

The BusinessServer half would do the things that are best done close to the
data tier.

The BusinessClient and BusinessServer are considered to be the same classin
that each has an intimate understanding of the internal workings of the
other.  In a fat client you can have a single class and simply serialise the
object state between tiers.  In Web apps I create the BusinessClient isin
JavaScript, BusinessServer is in C# and internal state is held as XML.

Could you suggest what control you would use for a numeric value?
Obviously an UpDownNumericPicker is appropriate for simple numbers.
But what about large numbers such as currency or other decimal
numbers? My users don't want to sit there clicking up and down for 12
minutes to get at $1234.56.

As for the MaskedTextBox, I have only ever had trouble with it. It is
weird about letting you click within it. My users hate it. Part of the
problem, as always, is that the user wants to speed of a plain textbox
with perfect validation.

 

[Anthony Jones]

One approach is to split the business object down the middle. Instead of a
three layer approach:-

UI -> Business -> Persistence

Use:

UI -> BusinessClient -> BusinessServer -> Persistence.

The BusinessClient runs on the same tier that the UI does, IOW its a
library
included in the UI app. Hence it can provide rapid feedback to the UI
which
would be bound more tightly. You just need to define interfaces that are
understood by the UI and allow the BusinessClient to describe things such
as
simple rule breaches.

I might just add though that the example of "must be a number" isn't a
good
one. You would expect the UI developer to use a control which simply
didn't
allow incorrect input of that nature in the first place. However missing
data would be exactly the sort of thing you would want the BusinessClient
to
inform the UI of.

The BusinessServer half would do the things that are best done close to
the
data tier.

The BusinessClient and BusinessServer are considered to be the same class
in
that each has an intimate understanding of the internal workings of the
other. In a fat client you can have a single class and simply serialise
the
object state between tiers. In Web apps I create the BusinessClient is in
JavaScript, BusinessServer is in C# and internal state is held as XML.

Could you suggest what control you would use for a numeric value?
Obviously an UpDownNumericPicker is appropriate for simple numbers.
But what about large numbers such as currency or other decimal
numbers? My users don't want to sit there clicking up and down for 12
minutes to get at $1234.56.

As for the MaskedTextBox, I have only ever had trouble with it. It is
weird about letting you click within it. My users hate it. Part of the
problem, as always, is that the user wants to speed of a plain textbox
with perfect validation.

MaskTextBox is evilness carried over from the early VB days. I wouldn't
touch it with a barge pole. It's shame we can't just turn off the updown
buttons in the Numericupdown. Sub-class the standard TextBox or TextBoxBase
and take charge yourself.

 

[Pavel Minaev]

Hello:

Is it me, or is handling the Validating event for every control on a
form extremely annoying? It is especially annoying when my business
logic repeats most of the validation. Some things you can handle in
the business logic. But other things, like ensuring a textbox
represents a number or null, requires a developer's intervention.

Not really. If you use data binding, and if validation in your business
entities take the form of exceptions, then you'll get seamless validation in
your UI. If the textbox is bound to an int property, user will be forced to
enter a number. And if that property will throw ArgumentException in its
settor for any value smaller than 0, then user won't be able to enter
negative numbers into it, either.

IDataErrorInfo is another interesting thing, and works wonderfully when you
bind through a BindingSource, and then throw ErrorProvider (with DataSource
pointing to that same BindingSource) onto the form. It won't block input,
though, just highlight the errors.