Is it correct to access the DAO layer from the Controller layer? [closed]_问答_开发者

Closed. This question is opinion-based. It is not currently accepting answers. 开发者_运维百科

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

Improve this 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!

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.

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.

You should bypass it to service layer.

Reasons for doing this :

Later you can put transaction management in this service layer.
In case you want to change the Controller Layer completely to other framework ( for example change struts to Spring MVC) if you put all the code calling DAO in the Service, It's easier to refactor ( You only need Spring MVC to call your existing Service). Imagine if you have to put all the DAO calling to your Spring MVC layer.

I guess I'm the iconoclast here. I agree with the answers given thus far that say bypassing the service layer is fine in principle, but in my humble opinion, it's not in practice.

The main reason is that it is hard to anticipate when business logic may some day be introduced. For example, I consider "logging" to be business logic. If I want to INTRODUCE logging or journaling or restrict access, I don't want to do that in the DAO layer. But if I have code that bypasses the DAO layer, now ALL that code needs to be refactored.

There's another advantage to the DAO layer that I have often found useful. There are operations I may want to expose to a service layer, but not to any layer above it.

As an example, I can imagine a DAO layer that returns encrypted passwords, but a service layer that only allows you to tell whether an encrypted password you pass in matches the one in the database. I don't want a controller layer being able to fetch valid encrypted passwords - I see that unnecessary exposure.

Thus while I might agree that if you KNOW for damned sure you never ever will need to introduce business logic (such as I've described), and if you have ZERO need to hide some data access operations while exposing others... then by all means expose the DAO layer to higher layers.

My point is that in practice, you can't "know" that, nor should you assume that.