从Controller层访问DAO层是否正确？

Question

在我的应用程序中，我通常访问 DAO 层，以获取/保存或更新对象的存储库，并使用服务层执行更复杂的操作

所以我的问题是：从控制器层访问 DAO 层是否正确（根据最佳实践和设计/架构模式），或者我应该绕过它通过服务层？谢谢！

Answer 1

理论上：在MVC架构模式的上下文中，数据访问层（DAO）和服务层之间没有明显的区别。服务层和DAO层都可以被视为MVC中的“模型”。服务层可能很好地实现业务逻辑，复杂的验证等等 - 但它仍然是访问数据的层！只要您在Model，View和Controller对象之间保持清晰的关注点分离，从Controller对象访问DAO层就是正确的。

实践中：我见过两种情景。如果您的应用程序具有简单的数据模型，则直接从控制器使用DAO层是有意义的。但是，由于业务逻辑变得复杂，或者您的模型由多个应用程序共享，因此将业务代表和DAO分解以重新使用组件，最小化更改时的影响，提高之间的灵活性更有意义。组件等。这将取决于相关系统的技术架构。

Answer 2

我认为如果不需要从服务层进行任何类型的处理，那么让Controller层直接访问DAO是没有问题的。但它确实应该至少进行某种处理，例如在弄乱数据库之前输入数据的服务器valitadion。

Answer 3

您应该将其绕过服务层。

执行此操作的原因：

1. 稍后您可以将事务管理放在此服务层中。
2. 如果您想将Controller层完全更改为其他框架（例如将struts更改为Spring MVC），如果您将所有代码调用DAO放入Service中，则更容易重构（您只需要Spring MVC来调用您的现有服务）。想象一下，如果你必须将所有DAO调用放到Spring MVC层。

Answer 4

我想我在这里是破坏者。我同意到目前为止所给出的答案，说绕过服务层原则 很好，但在我看来，

主要原因是很难预测何时可能会引入业务逻辑。例如，我认为“logging”是业务逻辑。如果我想INTRODUCE日志记录或日记或限制访问，我不想在DAO层中这样做。但是，如果我有绕过DAO层的代码，那么现在所有代码都需要重构。

我经常发现DAO层的另一个优势是有用的。我可能希望向服务层公开操作，但不向其上方的任何层公开。

作为一个例子，我可以想象一个DAO层返回加密密码，但是一个服务层只允许你判断你传入的加密密码是否与数据库中的密码相匹配。我不希望控制器层能够获取有效的加密密码 - 我看到不必要的曝光。

因此，虽然我可能同意如果你知道该死的确定你永远不需要引入业务逻辑（比如我所描述的），并且如果你有ZERO需要隐藏一些数据访问操作，同时暴露其他人。然后通过各种方法将DAO层暴露给更高层。

我的观点是，在实践中，你不能“知道”那个，你也不应该这样认为。