Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working on a small webservices project (java, axis2..). There is a lot of existing code, the code is divided into many layers, from the first layer where the request in interpreted to a few layers down to the dao layer. In the dao layer I'm seeing some validation code interspersed in a few places. The project contains tables which have multiple unique columns, so the user may input a single column or a combination of columns. The validation in dao layer is to check if such a combination exists, if not throw an exception.

I was told these kind of checks are more related to the schema and hence need to be in the dao layer. The dao interface has methods like 'checkIfThisExists/checkComboExists', Would this be a 'proper' design? I always thought the dao's job should only be to send and receive data, more like get and set.

share|improve this question

migrated from Jul 19 '11 at 14:12

This question came from our site for professional and enthusiast programmers.

up vote 2 down vote accepted

I think DAOs are for persistence. If I wanted to ensure integrity at the database level I'd do it in the database itself, but validation and binding should be completed long before data reached the DAO.

An incoming request to your web service should be validated and bound when it reaches the web service.

share|improve this answer

I usually go for this architecture, it's very standard and served me well countless times:

  • A common library with POCO and interfaces defined.
  • A data access layer based on a common interface so it is interchangeable. It will map the database tables to the POCO.
  • A business layer which will require an implementation of the DAL interface to work, and will inject business rules and validation on POCOs.
  • As many user interface layers as you need (web app, web service, etc.) that will only talk to the business layer, will know of the POCOs and will provide the BLL with the appropriate DAL through Inversion of Control.

This way you have everything decoupled, your "common stuff" is defined in an isolated namespace and you have a single core (the business layer) while you can have multiple interchangeable data layers and multiple concurrent user interface applications.

share|improve this answer

I don't see a problem with this. It sounds like data access logic, so it makes sense to restrict it to the data access layer. Doing this type of validation any higher would require an additional round-trip to the database, which would quickly get expensive (unless you can cache the required information easily).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.