Is it correct to access the DAO layer from the Controller layer? [closed]

Question

In my applications I usually access the DAO layer in order to obtain/save or update objects to it's repository, and I use a Service layer to perform more complex operations.

So my question is this: Is it correct (according to best practices and design/architecture patterns) to access the DAO layer from the Controller layer, or should I bypass it through the Service layer? Thanks!

Answer 1

In theory: within the context of the MVC architectural pattern, there is no clear distinction between a data access layer (DAO) and a service layer. The Service layer and the DAO layer could both be seen as the "Model" in MVC. A Service layer may well implement business logic, complex validations, etc. - yet it is still a layer for accessing your data! As long as you maintain a clean separation of concerns between your Model, View and Controller objects, it would be correct to access the DAO layer from a Controller object.

In practice: I have seen both scenarios. If you have a small application with a simple data model, it would make sense to use the DAO layer directly from Controllers. However, as business logic gets complicated, or if your model is shared by more than one application, it would make more sense to factor out Business Delegates and DAOs in order to re-use components, minimize impact when changes are made, increased flexibility between components, etc. This would be dictated by the technical architecture of the system in question.

Answer 2

I think that if there is no need for ANY kind of processing from the Service layer, there is no problem to have the Controller layer to access the DAO directly. But it should really have at least some kind of processing to do, like server valitadion of input data before messing with the database.