views:

534

answers:

3

Typically I have added data validation, such as checking that an input is within a certain range, in the data models found in my Data Access Layer. Searching the web I've seen that there are two schools of thought on the matter:

  1. Adding the validation as part of the Data Access Layer (like I have been doing)
  2. Adding the validation as part of the Business Layer

I can see good arguments on both sides, but in order to maintain a true separation of concerns, what is the recommended approach? Is there a one size fits all solution to this? or is it like most things and you have to analyze on a case by case basis?

+3  A: 

Validation is composed of two parts - the validation process and the validation rules. The validation process should be repeatable and abstracted at the DAL layer. The validation rules are a part of the business/domain logic since that logic determines what counts as valid data.

I usually define validation rules per model, which extends a DAL layer that can process those rules to determine if a certain data set is valid or not.

Eran Galperin
+1  A: 

If your validation routines preserve integrity of data, the data domain should validate them. Therefore, it's essential to do data-oriented validations in the database itself and DAL. However, business layer should also validate its input data separately and should make sure (with explicit checks) the actions it's doing on the data access layer are semantically correct.

Mehrdad Afshari
+1  A: 

I prefer to use business objects for validation. This makes you less dependent on the DAL and enables more flexibility in your application. In cases where you want to execute the same validation rules in different layers you can even split out validation to a separate component that you can call from your business objects, your presentation layer or your DAL. This gives you even more flexibility without duplicating code.

Mendelt