Design principles - data conformance / business logic in the data access layer?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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).