Best practice for validating input data for multi-tier application [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this question

In our application we have various layers. Service Layer, DAO layer and actions (struts applications).

Data gets passed from one layer to another layer.

Where we should ideally put input validation ?

Say, userid, phone number is coming from UI, They are mandatory. So we are already doing validation at client side.

Now, As per my opinion, Thts all u need. No where else it should be validated.

But one of my colleague argues, wh开发者_如何转开发at if client makes request directly. So we need to add in Actions also.

Now, At Dao as well, same method is getting used at some other action and tht does not have validation,

Or, Say service layer, It might be exposed as , say as web service, So there also u shd have validation.

So essentially, He is suggesting..we shd have validations everywhere. Which does not make sense for me. Its duplication across layer.

What is ideal approach for this ? Say validation is of may be simple null check or some complex validation.

---

Agree with Pangea, you should definitely have validations in the client and service endpoints.

I would add that the concept of validations is to be "fail-fast". You add validations to each layer so that the user or caller would get immediate feedback as to why the call would fail instead of potentially starting a transaction, making complex queries and doing a write only to find that a field is too short.

On the client-side, you want as much validation as possible so that you won't waste the user's time, bandwidth and server-side resources (which have contentions in many cases). However, you usually can't do all validations on the client-side (for example, to check for whether there is already such a username in use on signup) so you would want that checked and a proper error message returned as soon as you hit the service layer.

On the server layer, you want to assume that all inputs are potentially dangerous and incorrect (and they often times will be). I actually think it's better to be more comprehensive and aggressive on validating inputs on the service layer since that's your last line of defense. If you leave out a validation or two on the client side, you just need a nice fault handling mechanism to let the users know what's wrong. If you miss something on the service side and disaster strikes, it could mean hours or days of debugging and trying to restore database backups.

There are some checks that are done at the database level as well which enforce things like referential integrity and such. I usually try as much as possible to check for them before attempting a write since interpreting various RDBMS's error messages and trying to convert them back to user understandable lingo is often hard if not impossible.

---

If your application provides multiple entry points (UI or system to system interfaces or batch systems) then you should cleanse (null checks, format checks, required-ness etc) your data at all of these edges and before it reaches the service layer. But this doesn't mean you need to replicate your validation logic. You can use frameworks that allow you to centralize your validation. Some example validation frameworks can be found in this post.

However, there are business validations that should belong to your domain layer and they should remain in your domain service layer or domain objects.

I do not agree that you should be performing validation in DAO's. DAO's should just be responsible for CRUD operations. If they are doing more then you have leaky layers. If you have to process stuff in batch then you should make sure the batch comes through service layer so that your batch is also going through the same validations.

---

The one piece of wisdom I can add to the conversation is, never trust the client. Whether your client be in HTML, Flash/Flex, or whatever, there is a possibility that someone is going to hack it and try to do something that you don't want them to do. The follow up here is, if there is a possibility that someone is going to hack it, we as software engineers must assume that it IS going to get hacked, so while checks on the front end are nice, and can aid in your applications usability, you MUST validate all your inputs on the back end, even if that leads to duplicate checks.