Data validation - Best practice - at what level

[Rick Smith]

Appologies if this is not the appropriate section for this question.

Background:

I'm currently working on a project using Struts, Spring and Hibernate with an SQL Server 2005 backend DB.

I've been putting in UI validation to provide the user with decent error messages in the presentation tier know that at some point I need to make allowences in my overall design for more some form of validation in tune with the 'busniess rules'.

Early testing threw up an error from the DB itself, it seems the DB data type of DATESTAMP does not allow dates before January 1, 1753 although this is generally not a problem if the use were to specifiy a date like this an excepion would be thrown.

Problem:
I was lookign for some advice on the best practice for adressing this type of validation.

If I allow the route exception to be caught the user will get more general errors for a limitation of the underlayer system, even though they have supplied a valid date.

It doesn't seem appropriate to encode this limitation into my UI (struts validation frameworks) so where should it go int the buiness tier, between the presentation and business tiers or is it actually appropriate to have the persistance layer have the final say on what might be out of handled value bounds?

The problem I see with letting the lower tiers do additional validation is the repertition of validation already done in the UI and also the addition effort in providing enough handling to give the user enough feedback to know what they've done wrong.

Any advice is much appreciated.

[Jimmy Clark]

In the UI, users should not be "enabled" to enter faulty data such as a year of 1753. The UI should be designed, as much as possible, to only permit valid data entry, e.g HTML select box with only valid years. This practice reduces the amount of "validation" that may be coded in the UI.

Validation of data should be coded in Business tier code.

[Vikrama Sanjeeva]

Originally posted by James Clark:
In the UI, users should not be "enabled" to enter faulty data such as a year of 1753. The UI should be designed, as much as possible, to only permit valid data entry, e.g HTML select box with only valid years. This practice reduces the amount of "validation" that may be coded in the UI.

Validation of data should be coded in Business tier code.

I agree with emphasis on UI validations. Select boxes are populated from server side and its the best way to restrict user to for fields like date, year etc.

However, for input box checks like email validation, amount digit validation etc, normally JavaScript is used. But I think, its better to do server side validation (along with client JS) so that if user manages to skip JS validation; then server should not overlook it.

Bye,
Viki.

[Rick Smith]

Thank you for the replies.

So to clarify my understanding, the approach should be to avoid the need for the business tier's own validation to pass validation feedback to the presentation tier (to give a reason for a failure to the user).

We say this because the presentation tier should do all validation needed to ensure it does not pass any data back to the business tier that is invalid, if it does this is a 'true' exception.

Therefore if the business tier does it's own validation and decides a value is incorrect for some reason (perhaps the code has been changed out of synch) it can treat the failure by throwing an exception back up.

Is this the correct interpretation?

[Jimmy Clark]

Therefore if the business tier does it's own validation and decides a value is incorrect for some reason (perhaps the code has been changed out of synch) it can treat the failure by throwing an exception back up.

The significant value of validation on the Business tier is that it fosters loose coupling between the business application code and the presentation code, i.e. extensibility, adaptability, etc.

You could easily create new Presentation modules, e.g. wireless devices, that use the business application and not have to recode core validation logic. The development time for such a new module will be faster and easier to test.

Business tier should return either data or messages/signals back to Presentation tier. In other words, it should not return Java exceptions.
Code in the Presentation tier should not have to handle "exceptions" from the Business tier. The code in the business logic should handle its own exceptions and return the data that was requested or a message/signal that indicates a problem.

It looks like to you got the idea. Keep it moving
[ November 12, 2008: Message edited by: James Clark ]

[Mike Dev]

This is an interesting discussion, since I am currently dealing with a similar problem.

Currently, we are using the MVC pattern to separate the various components (we also have a Data Access Layer). However, my biggest concern is with the validation of data. I agree that the user should not be allowed to enter invalid data, but I also wonder where and how the validation should occur. Currently, this is what we have:

1) Javscript together with regular expressions to validate email addresses, length of texts, etc.
2) using the same regular expressions in the Model (setter methods) to ensure that the data is valid.
3) Perform some additional business rules validations within the services.

We decided to do so, since there might be new user interfaces or web services that need to use the functionalities provided by the services. Therefore, keeping the validation on the user interface was not enough.

However, since the validation is growing (for example, a single field/property of a business object could be validated for its length, correct format, and whether it is mandatory or not). This makes a few validations on the Model that I don't really know how to deal with it, from an architectural point of view.

Sorry for this long message, but I needed to give some background information.

What do you think? I would be grateful for any comment, but especially with links to articles or resources that could help me out.

Thanks.
Mike

[Jimmy Clark]

Your data access layer would be considered part of the Model. There is no real need to point it out or think of it as a "fourth" element in the design.

However, since the validation is growing (for example, a single field/property of a business object could be validated for its length, correct format, and whether it is mandatory or not). This makes a few validations on the Model that I don't really know how to deal with it, from an architectural point of view.

Please explain in more detail what validations in the Model you are referring to. This information will help us identify a good design.
[ November 13, 2008: Message edited by: James Clark ]

[Mike Dev]

What I mean is that, for example, a transaction is made up of different values (negative and positive). In order to be able to save a transaction, the sum of the items must be zero. This is a validation that has to do with the user interface and with the Business Layer/Model. For instance, if we imagine a system that includes both a Web UI and a web service, the transaction's validation will need to occur in the Business Layer/Model.

I was thinking that this validation might be considered as an "extension" of the Model, but then I do not really know how to put the pieces together. Or is there a better approach? How can this validation be configured (if at all needed)? What is your suggestion?

I also appreciate any suggestion on reading material about such concepts, since I am new to architecture, but am really very interested in the subject.

Thanks.
Mike

[Jimmy Clark]

These concepts and issues concern object-oriented analysis & design, not architecture. Model-View-Controller is an object-oriented design pattern.

What I mean is that, for example, a transaction is made up of different values (negative and positive). In order to be able to save a transaction, the sum of the items must be zero. This is a validation that has to do with the user interface and with the Business Layer/Model.

Why do you think this validation should occur in the user interface (View)?

The logic in the business application (Model) will determine whether to save the transaction or not, i.e. check the sum of the items.

The logic in the business application (Model) will do the arithmetic to get the sum.
[ November 13, 2008: Message edited by: James Clark ]

[Mike Dev]

I hope I am not posting to the wrong forum.

I agree with you that the validation should not occur in the user interface. The user interface only has to get the validation errors, if any, and display them to the user.

I also agree when you say that business application (Model) will have the logic and validations that I explained in my example. However, it is how to design the classes and components that I am not sure about.

Is there any sample application from which one could start from? I am not asking for someone to give me an application; just wondering whether some book or tutorial or studying material that I could look at to get a better idea. I must admit, I am a bit confused...

Thanks anyway for all your input James!

[Jimmy Clark]

It takes a couple of years to learn object-oriented analysis and design effectively. This includes practice and study. There really is no shortcut. There are many different ways to design and many different ways to interpret requirements and design options. Over time, things will get easier and you will develop your own style of design and process.

My suggestions are to learn how to design with UML symbols and diagrams, read and study the GOF object-oriented design patterns.

Good luck!

[frank davis]

Originally posted by James Clark:
[QB]These concepts and issues concern object-oriented analysis & design, not architecture. Model-View-Controller is an object-oriented design pattern.



Why do you think this validation should occur in the user interface (View)?

QB]

User conveneince to save a round trip to the web server? (not that validation should not also occur at business logic level)

[Danilo Dadonas]

If you just put validate in the view it should not solve the problem. If you have a select with options listed from the server, you can hack it adding values using some free tools. In this case the user can put wrong values if the business tiers isn't validating the data. I've used AJAX to validate some simple features like if the value is a string, number, the length, etc. After the submit, the data is filtered by the business tier where the simple features are validated again + the business rules. I this case I'm using Hibernate Validator. After the business validation, the object is submited to the Data Access Tier where it is ready to be persisted. Pretend you are registering a customer; the class model should be:

customer.jsp > customer_validator.js > CustomerAction > CustomerBO > CustomerDAO > Repository

bye.

[ December 01, 2008: Message edited by: Danilo Dadonas ]
[ December 02, 2008: Message edited by: Danilo Dadonas ]