views:

129

answers:

4

I'm feeling a little conflicted at the moment. I have a web application using Stripes for an MVC framework and Spring/Hibernate for the back-end. I have an account registration method in my MVC layer which requires the following validation:

  • Username is not already taken
  • The provided email address is not already associated with another account

I have a validation method in Stripes (MVC layer) that checks these two cases but was wondering whether my service layer should duplicate these checks? If the service layer interface was exposed as a web service then I think the validation would be a good idea, but if it's only used in the context of a web application is it required?

Edit: I'm not intending to duplicate the validation code - I mean duplicating the validation method calls in two places.

I see my options as:

  1. Duplicate the validation calls in both MVC and service layer
  2. Only perform this validation in the MVC layer
  3. Only perform this validation in the service layer.

What's best practice here? I'm looking for advice/opinions on which option I should go with and why.

Note that there are simple validation checks on the input fields of the registration form (like checking for blanks) and that I think these should be handled by the MVC validation only; I'm only concerned about more complex validations.

+4  A: 

Don't duplicate code. Use JSR303 Bean Validation so you can use the same validation logic in all layers of your app.

Hibernate Validator (a separate project from the Hibernate ORM stuff) provides the reference implementation of this interface. It is dead simple to use, you can get started with it very quickly.

matt b
Yep, I don't mean I'll be duplicating the validation code - I mean I'll be calling the same validation code in two places
Annie
Well as you mentioned then you really have a need to do validation twice, in case you have other clients besides the controller layer. Potentially I could see potentially wanting to have different validation logic as well
matt b
A: 
  1. Ideally, do the validation in both layers, since your service layer may be used with a client other than the current mvc layer

  2. Reuse the validation mechanism at both places (Bean validation, for example)

Bozho
+2  A: 

In my opinion you should diferenciate two kinds of validations:

  • The Format data validation: Which should be validated in the presentation layer (MVC in your case). Normally both in the client and the server side
  • The Bussines data validation: Which should be validated in the service layer

In your case your validations are related to business rules, so I will put them only in the service layer. In addition, if you duplicate your validations in both layers you will be making the same queries twice, slowing down the performance of your application.

Pau
+1  A: 

Annie,

Good question, I have asked myself the same in many occasions. Here's what I ended up with (until now).

The purest (but tedious) approach is to invoke the validation logic in both layers. the pragmatic approach could be to only invoke it in web-land (e.g. your controllers).

I think there is no answer that ends all discussion. I think that it depends on the context of your project. If the project-size is modest (in terms of people and size of codebase) and you are confident that not a whole lot of code will be developed by others that invoke your service API (to an extent that you will not be able to oversee), then doing the validation in the web-layer only may well suffice.

However, if you expect many clients you may need a higher-level security. When I say security here, I refer to it as the level of consistency-guarantees that you need. If that level is high, there is no way around it: you will have to do it in both the service (for security) and the web layer (mostly to be able to provide end-users with an acceptable experience).

So the key driver here is security and how much of it you really need. If you need a lot, you go for the 'purist' approach. If your application doesn't exactly make decisions that concern matters of life and death, you go for the pragmatic approach.

Hans Westerbeek