Business Rule Validation

[SiJP]

I am creating a new winforms project using Visual Studio 2005. The
project is converting a paper-based application form into an
electronic one.


I need help implementing a correct method for 'Business Rules'
validation.


The paper-based form has 50 fields that vary in their content (some
are yes/no options, some are numeric fields, others are one field
allowing multiple lines).

Each field can have several rules associated with it, for example:

Field_1
- Must be either "A1", "A2", "A3" or "A4"
- Cannot be A3 if Field_3 is 3 or 5
- This field cannot be left blank

Field_2
- Must not be completed if Field_1 is A1 or A2
- Can only be completed if Field_3 is 3 or greater
- The number in this field must be equal to Field_4 plus Field_3
minus 2 if Field_4 is less than 2

Field_3
- Must be between 1-10
- Cannot be left blank
- Cannot be greater than 5 if Field_4 is less than 2

....


These are slightly fictional (but fundamentally similar to the actual)
rules.

The data being captured needs to be validated locally on our clients'
PC, before being transmitted as an XML document to a service on our
webserver. Each field will have other formatting rules assiciated
with it (length, data types etc) and I'm not sure if these would be
considered part of the business rules or best dealt with from the UI.

(I don't particularly want to do what I use to do in vb6, which is to
create a rule for each after_update event of the field!!)

I would appreciate any help, but sample code would be awesome! (vb.net
or c#)

 

[Sheng Jiang[MVP]]

search for "rules driven UI using WF"

 

[Mr. Arnold]

I am creating a new winforms project using Visual Studio 2005. The
project is converting a paper-based application form into an
electronic one.


I need help implementing a correct method for 'Business Rules'
validation.


The paper-based form has 50 fields that vary in their content (some
are yes/no options, some are numeric fields, others are one field
allowing multiple lines).

Each field can have several rules associated with it, for example:

Field_1
- Must be either "A1", "A2", "A3" or "A4"
- Cannot be A3 if Field_3 is 3 or 5
- This field cannot be left blank

Field_2
- Must not be completed if Field_1 is A1 or A2
- Can only be completed if Field_3 is 3 or greater
- The number in this field must be equal to Field_4 plus Field_3
minus 2 if Field_4 is less than 2

Field_3
- Must be between 1-10
- Cannot be left blank
- Cannot be greater than 5 if Field_4 is less than 2

...


These are slightly fictional (but fundamentally similar to the actual)
rules.

The data being captured needs to be validated locally on our clients'
PC, before being transmitted as an XML document to a service on our
webserver. Each field will have other formatting rules assiciated
with it (length, data types etc) and I'm not sure if these would be
considered part of the business rules or best dealt with from the UI.

(I don't particularly want to do what I use to do in vb6, which is to
create a rule for each after_update event of the field!!)

I would appreciate any help, but sample code would be awesome! (vb.net
or c#)

Business rules should be in the Business bject or the Business layer and not
at the UI. When the Save method is invoked on the Business object from the
UI, the Business object validates itself. If the Business object is valid,
then it proceeds with the Save of its data weather the data is being
persisted to a DAL object, to some XML situation, or the Save of the
Business object is rejected and errors are reported back to the UI from the
Business object to be displayed to the user.

The UI populates the Business object, the Business object validates itself
with its business rules. The Business object is valid or it's not valid
with the appropriate action taken to save its data or reject the save and
report errors with itself back to the UI.

You need to understand OOp's programming, and you need to understand design
concepts. You need to understand how and why to abstract business rules
from the UI as much as possible.

This may give you better insight about OOp's programming using .Net VB or
C#, about the UI/Business Layer/Data Access Layer, why application
design/logic should be abstracted from other layers, and layers loosely
coupled whether it be a Windows Desktop Or Web application.
MODEL-VIEW-PRESENTER

http://www.polymorphicpodcast.com/

click 'Shows'

click 'Design Patterns Bootcamp: Model View * Patterns*

view parts 1-5

You can use Google to get more information about this or find books.

You should also understand an object's Public accessor properties of Get/Set
in C# or Let/Get in VB.Net.

 

[sloan]

Check this blog entry for a Layered Application:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry


Then, check
http://davidhayden.com/blog/dave/ar...nApplicationBlockEnterpriseLibrary3PartI.aspx

or google "Validation Application Block" This a new(er) EnterpriseLibrary
component.


You can add rules to your business objects either thru attributes, or via a
config file.

It should give you some options.

 

[Guest]

Business rules should be in the Business bject or the Business layer
and not at the UI. When the Save method is invoked on the Business
object from the UI, the Business object validates itself. If the
Business object is valid, then it proceeds with the Save of its data
weather the data is being persisted to a DAL object, to some XML
situation, or the Save of the Business object is rejected and errors
are reported back to the UI from the Business object to be displayed
to the user.

Yes, but wouldn't it be nice for the GUI to provide some real-time feedback
to the user?

 

[sloan]

You can still send information back to the client side.

One way is custom exceptions. (Though you don't want to go nutso on custom
exceptions).



public class InvalidCreditCardVerficationException :
System.ApplicationException // or extend from System.Exception, the best
practices argument keeps see sawing

{

public InvalidCreditCardVerficationException ()

: base("General InvalidCreditCardVerficationException ")

{

}

public InvalidCreditCardVerficationException (string errorMsg)

: base(errorMsg)

{

}

}




Then you can throw a custom exception like this:



if( CreditCard.ExpireDate < DateTime.Now ) //pseudo code
{
throw new InvalidCreditCardVerficationException( string.Format ("The credit
card expiration date of {0} is in the past, please correct the date.",
CreditCard.ExpireDate.ToShortDateTime() ) ;
}


Something like that.

However, if you look at the Validation Application Block, they handle this
without throwing exceptions. But you still pass useful information back to
the presentation layer.

Let me give you a rule of thumb.... for the business layer.

"If I needed to take my web application and make it into a winforms
application (or vice versa), what can I push down into the business logic
layer to AVOID duplication of code."

Even if you never, ever, never, ever, ever think you'll do a vice-versa
version, you should think this way.

Therefore all logic checks should go into the business layer and NOT the
presentation layer.

...
The one caveat is asp.net and javascript. You may want to put simple
javascript validation in your presentation layer to avoid a trip to the
server.
But I mean simple.
"Did the user put in a string for LastName?"
Did the user pick something from a drop down list?
even, "Is the credit card exp date in the past?"

YOU STILL NEED TO PUT THESE CHECKS IN THE BIZ layer as well. Don't skimp.


Here is a useful article as well.
http://blogs.msdn.com/kcwalina/archive/2005/03/16/396787.aspx

Which I believe the Validation Application Block implements well.

 

[Mr. Arnold]

Yes, but wouldn't it be nice for the GUI to provide some real-time
feedback
to the user?

It may come that you have some checking for required fields not left blank
when you press the Save or Submit button, things of that nature and stop it
at the UI. But business rules should be abstracted from the UI. The UI
should be unaware of the business rules. The business object validates
itself or its data within the business object. Either data within in the
business object is valid or it's not valid based upon the business rules of
the business object.

In today's environment and using something like Model View Presenter/MVP
which ensures the abstraction of the UI from the Business and other layers,
one should be able to validate/test the solution by using Interfaces to/from
the Business Layer down to something like the DAL, which can be accomplished
by using something like Nunit where the UI is not even involved in the
testing. Better testing can be done which leads to a better overall
application that the end-user is using.

 

[SiJP]

Some good replies here, for that I am very grateful.

Sheng Jiang: I will be using .Net 2.0 for this project so WF is not an
option for me.

Mr Arnold: This is the approach I had been hoping to be suggested. I
have done 'some' research into business objects, and it is reassuring
to know it appears the right route to take. Regarding OOP, the
concepts are not lost on me but the link you gave has some great info
that has helped.

Sloan: Validation Application Block again is a .net 3 thing (I
think?!) which isn't an option for me (due to client os's).



More research needed I think!
Cheers guys